จะปรับ php5 + MySQL ให้สูงกว่า 200 คำร้องขอ / วินาทีได้อย่างไร?


16

ฉันกำลังปรับแต่งหน้าแรกของฉันเพื่อประสิทธิภาพขณะนี้สามารถจัดการได้ 200 คำขอ / วินาทีใน 3.14.by ซึ่งกิน 6 คิวรี่ SQL และ 20 รีคิว / วินาทีบน 3.14.by/forum ซึ่งเป็นฟอรัม phpBB

น่าแปลกที่ตัวเลขมีความเหมือนกันใน VPS และเซิร์ฟเวอร์ Atom 330 โดยเฉพาะ

ซอฟต์แวร์เซิร์ฟเวอร์มีดังต่อไปนี้: Apache2 + mod_php prefork 4 childs (ลองตัวเลขที่แตกต่างกันที่นี่), php5, APC, nginx, memcached สำหรับการจัดเก็บเซสชัน PHP

MySQL ถูกกำหนดให้กิน RAM ประมาณ 30% (~ 150Mb บน VPS, 700Mb บนเซิร์ฟเวอร์เฉพาะ)

ดูเหมือนว่ามีคอขวดบางแห่งที่ไม่ยอมให้ฉันไปสูงกว่านี้มีข้อเสนอแนะอะไรบ้าง? (เช่นฉันรู้ว่าการทำ SQL น้อยกว่า 6 จะทำให้เร็วขึ้น แต่สิ่งนี้ดูเหมือนจะไม่เป็นปัจจัยที่ จำกัด เนื่องจาก sqld กินได้ไม่เกินสองสาม% เนื่องจากแบบสอบถามที่เก็บไว้)

มีใครทดสอบว่าการเตะ apache2 preforked และปล่อยให้เพียงแค่ nginx + php เร็วกว่ามากไหม?

มาตรฐานเพิ่มเติมบางอย่าง

Small 40-byte static file: 1484 r/s via nginx+apache2, 2452 if we talk to apache2 directly. 
Small "Hello world" php script: 458 r/s via ngin+apache2.

อัปเดต: ดูเหมือนว่าคอขวดคือประสิทธิภาพของ MySQL ในข้อมูลแคช เพจที่มี SQL เดี่ยวแสดง 354req / วินาที, 6 SQL's - 180 req / วินาที คุณคิดว่าฉันสามารถปรับแต่งที่นี่ได้อย่างไร (ฉันสามารถแยกออกจาก 100-200Mb สำหรับ MySQL)

[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
default-character-set=cp1251
collation-server=cp1251_general_cs

skip-character-set-client-handshake

user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
skip-external-locking

bind-address        = 127.0.0.1

key_buffer      = 16M
max_allowed_packet  = 8M
thread_stack        = 64K
thread_cache_size   = 16
sort_buffer_size    = 8M
read_buffer_size    = 1M

myisam-recover      = BACKUP
max_connections        = 650
table_cache            = 256
thread_concurrency     = 10

query_cache_limit       = 1M
query_cache_size        = 16M

expire_logs_days    = 10
max_binlog_size         = 100M

[mysqldump]
quick
quote-names
max_allowed_packet  = 8M

[mysql]
[isamchk]
key_buffer      = 8M

!includedir /etc/mysql/conf.d/

ทำไมคุณถึงใช้ทั้ง Apache และ nginx
jamieb

นั่นคือการกำหนดค่าทั่วไป, Apache2 ถึง PHP และแอพต่าง ๆ ที่ต้องการโครงสร้างพื้นฐาน apache, nginx เพื่อลดรอยเท้าหน่วยความจำ apache2 ในการโหลด
BarsMonster

จริงๆแล้วฉันไม่เข้าใจปัญหาของคุณ เว็บไซต์ของคุณช้าหรือไม่ ถ้าเป็นเช่นนั้นมันช้าแค่ไหน? และคุณต้องการเพิ่มความเร็วเท่าไหร่ คุณพยายามที่จะโพรไฟล์ส่วนใดของเว็บไซต์ของคุณเพื่อตรวจสอบว่าคอขวดอยู่ที่ไหน?
jamieb

มันอยู่ในคำอธิบาย: ตอนนี้มันอยู่ที่ 180-200 คำร้องขอ / วินาที แม้ว่าจะเป็นวิธีที่มากพอสำหรับหน้าแรก แต่ฉันต้องการปรับแต่งการตั้งค่านี้เพื่อให้ไซต์อื่น ๆ ที่สร้างขึ้นบน codebase เดียวกันทำงานได้เร็วขึ้น เป็นการดีที่ฉันต้องการเชื่อมต่อ 100Mbit กับหน้าไดนามิก :-)
BarsMonster

2
"คำขอต่อวินาที" ไม่ใช่ตัวชี้วัดที่มีความหมายในบริบทนี้ เน็ตบุ๊กของฉันสามารถรองรับ "200 คำขอต่อวินาที" คุณต้องบอกเราว่าเวลาตอบสนองใดที่คุณต้องการบรรลุภายใต้อัตราการเชื่อมต่อแบบนั้น
jamieb

คำตอบ:


29

เห็นได้ชัดว่ามีหลายสิ่งที่คุณสามารถลองได้ ทางออกที่ดีที่สุดของคุณคือการติดตามบันทึกการสืบค้นที่ไม่ได้ใช้ดัชนี (เปิดใช้งานบันทึกการค้นหา) และการค้นหาที่ไม่เหมาะสมอื่น ๆ ฉันได้รวบรวมรายการตัวเลือกที่เกี่ยวข้องกับประสิทธิภาพไว้มากมายในช่วงหลายปีที่ผ่านมาดังนั้นฉันจึงได้รวมชุดย่อยขนาดเล็กไว้สำหรับข้อมูลของคุณด้วยหวังว่ามันจะช่วยได้ ต่อไปนี้เป็นบันทึกทั่วไปสำหรับสิ่งที่คุณสามารถลองได้ (หากยังไม่ได้ทำ):

MySQL

  • query_cache_type = 1 - คิวรี SQL แคชเปิดอยู่ หากตั้งค่าเป็น 2 แบบสอบถามจะถูกแคชเฉพาะเมื่อคำใบ้ SQL_CACHE ถูกส่งผ่านไปยังพวกเขา ในทำนองเดียวกันกับประเภท 1 คุณสามารถปิดใช้งานแคชสำหรับการสืบค้นเฉพาะด้วยคำใบ้ SQL_NO_CACHE
  • key_buffer_size = 128M (ค่าเริ่มต้น: 8M) - บัฟเฟอร์หน่วยความจำสำหรับดัชนีตาราง MyISAM บนเซิร์ฟเวอร์เฉพาะให้ตั้งค่า key_buffer_size เป็นอย่างน้อยหนึ่งในสี่ แต่ไม่เกินครึ่งหนึ่งของจำนวนหน่วยความจำทั้งหมดบนเซิร์ฟเวอร์
  • query_cache_size = 64M (ค่าเริ่มต้น: 0) - ขนาดของแคชแบบสอบถาม
  • back_log = 100 (ค่าเริ่มต้น: 50, สูงสุด: 65535) - คิวการร้องขอการเชื่อมต่อที่ค้างอยู่ จะเกิดขึ้นเมื่อมีการเชื่อมต่อจำนวนมากในเวลาอันสั้น
  • join_buffer_size = 1M (ค่าเริ่มต้น: 131072) - บัฟเฟอร์ที่ใช้เมื่อสแกนเต็มตาราง (ไม่มีดัชนี)
  • table_cache = 2048 (ค่าเริ่มต้น: 256) - ควรเป็น max_user_connections คูณด้วยจำนวนสูงสุดของการเข้าร่วมแบบสอบถาม SQL ที่หนักที่สุดของคุณประกอบด้วย ใช้ตัวแปร "open_tables" ในช่วงเวลาเร่งด่วนเพื่อเป็นแนวทาง ดูที่ตัวแปร "open_tables" ด้วย - ควรใกล้กับ "open_tables"
  • query_prealloc_size = 32K (ค่าเริ่มต้น: 8K) - หน่วยความจำแบบต่อเนื่องสำหรับคำสั่งแยกวิเคราะห์และดำเนินการ เพิ่มขึ้นหากมีคำสั่งที่ซับซ้อน
  • sort_buffer_size = 16M (ค่าเริ่มต้น: 2M) - ช่วยในการเรียงลำดับ (การดำเนินการตามสั่งและจัดกลุ่มตาม)
  • read_buffer_size = 2M (ค่าเริ่มต้น: 128K) - ช่วยในการสแกนตามลำดับ เพิ่มขึ้นหากมีการสแกนตามลำดับจำนวนมาก
  • read_rnd_buffer_size = 4M - ช่วยตาราง MyISAM เพิ่มความเร็วในการอ่านหลังการเรียงลำดับ
  • max_length_for_sort_data - ขนาดแถวที่จะเก็บแทนตัวชี้แถวในไฟล์เรียงลำดับ สามารถหลีกเลี่ยงการสุ่มอ่านตาราง
  • key_cache_age_threshold = 3000 (ค่าเริ่มต้น: 300) - เวลาในการเก็บแคชคีย์ในเขตร้อน (ก่อนที่มันจะถูกลดระดับ)
  • key_cache_division_limit = 50 (ค่าเริ่มต้น: 100) - เปิดใช้งานกลไกการไล่แคชที่ซับซ้อนยิ่งขึ้น (สองระดับ) หมายถึงเปอร์เซ็นต์ที่จะเก็บไว้สำหรับระดับล่าง delay_key_write = ALL - บัฟเฟอร์คีย์ไม่ได้ถูกลบทิ้งสำหรับตารางในทุก ๆ การอัพเดตดัชนี แต่เฉพาะเมื่อปิดตาราง ความเร็วนี้เพิ่มความเร็วในการเขียนบนคีย์มาก แต่ถ้าคุณใช้คุณสมบัตินี้คุณควรเพิ่มการตรวจสอบอัตโนมัติของตาราง MyISAM ทั้งหมดโดยเริ่มเซิร์ฟเวอร์ด้วยตัวเลือก --myisam-recovery = BACKUP, FORCE
  • memlock = 1 - ล็อคกระบวนการในหน่วยความจำ (เพื่อลดการสลับเข้า / ออก)

อาปาเช่

  • เปลี่ยนวิธีการวางไข่ (เป็น mpm เป็นต้น)
  • ปิดการใช้งานบันทึกถ้าเป็นไปได้
  • AllowOverride ไม่มี - เมื่อใดก็ตามที่เป็นไปได้ปิดการใช้งาน. htaccess มันหยุด apache สำหรับการค้นหาไฟล์. htaccess หากไม่ได้ใช้งานเพื่อบันทึกการร้องขอการค้นหาไฟล์
  • SendBufferSize - ตั้งเป็นค่าเริ่มต้นของระบบปฏิบัติการ บนเครือข่ายที่แออัดคุณควรตั้งค่าพารามิเตอร์นี้ใกล้กับขนาดของไฟล์ที่ใหญ่ที่สุดที่ดาวน์โหลดมาตามปกติ
  • KeepAlive Off (ค่าเริ่มต้นเปิด) - และติดตั้ง lingerd เพื่อปิดการเชื่อมต่อเครือข่ายอย่างถูกต้องและเร็วขึ้น
  • DirectoryIndex index.php - เก็บรายชื่อไฟล์สั้นและสมบูรณ์ที่สุด
  • ตัวเลือก FollowSymLinks - เพื่อทำให้กระบวนการเข้าถึงไฟล์ใน Apache ง่ายขึ้น
  • หลีกเลี่ยงการใช้ mod_rewrite หรืออย่างน้อย regex ที่ซับซ้อน
  • ServerToken = แยง

PHP

  • variables_order = "GPCS" (หากคุณไม่ต้องการตัวแปรสภาพแวดล้อม)
  • register_globals = Off - นอกจากความเสี่ยงด้านความปลอดภัยแล้วยังมีผลต่อประสิทธิภาพ
  • เก็บ include_path ให้น้อยที่สุดเท่าที่จะทำได้ (หลีกเลี่ยงการค้นหาระบบไฟล์เพิ่มเติม)
  • display_errors = Off - ปิดใช้งานการแสดงข้อผิดพลาด แนะนำอย่างยิ่งสำหรับเซิร์ฟเวอร์ที่ใช้งานจริงทั้งหมด (ไม่แสดงข้อความผิดพลาดที่น่าเกลียดในกรณีที่เกิดปัญหา)
  • magic_quotes_gpc = ปิด
  • magic_quotes _ * = ปิด
  • output_buffering = บน
  • ปิดใช้งานการบันทึกถ้าเป็นไปได้
  • expose_php = ปิด
  • register_argc_argv = ปิด
  • always_populate_raw_post_data = ปิด
  • วางไฟล์ php.ini โดยที่ php จะค้นหาก่อน
  • session.gc_divisor = 1,000 หรือ 10,000
  • session.save_path = "N; / path" - สำหรับเว็บไซต์ขนาดใหญ่ให้พิจารณาใช้ แยกไฟล์เซสชั่นออกเป็นไดเรกทอรีย่อย

ระบบปฏิบัติการ Tweaks

  • เมานต์ใช้ฮาร์ดดิสก์กับตัวเลือก -o noatime (ไม่มีเวลาเข้าถึง) เพิ่มตัวเลือกนี้ในไฟล์ / etc / fstab ด้วย
  • ปรับแต่ง / proc / sys / vm / swappiness (จาก 0 ถึง 100) เพื่อดูว่าอะไรมีผลดีที่สุด
  • ใช้ RAM Disks - mount --bind -ttmpfs / tmp / tmp

นั่นคือรายการที่ดีฉันมีส่วนใหญ่แล้วและเมื่อฉันเพิ่มสิ่งที่เหลืออยู่ประสิทธิภาพก็ไม่เพิ่มขึ้น ดูเหมือนคอขวดจะอยู่ระหว่าง PHP และ MySQL ไม่สามารถจัดการมากกว่า 800 คำขอต่อวินาทีจากแบบสอบถามแคช ...
BarsMonster

ตกลงคุณจะเชื่อมต่อกับฐานข้อมูล (mysql_pconnect () แทน mysql_connect () ได้อย่างไร? คุณใช้การเชื่อมต่อแบบถาวรหรือไม่ ลองทั้งสองวิธี ...
อีวาน Peevski

ฉันใช้การเชื่อมต่อแล้วและการรวมการเชื่อมต่อถูกเปิดใช้งานใน php.ini ... : -S
BarsMonster

เพียงเพื่อความสมบูรณ์ฉันจะลองเชื่อมต่อ ฉันเคยเห็นกรณี (โดยเฉพาะในการทดสอบโหลด) ที่มีประสิทธิภาพดีกว่า
Ivan Peevski

1

หากคอขวดไม่ใช่ CPU แสดงว่าเป็น IO - ทั้งเครือข่ายหรือดิสก์ ดังนั้น .. คุณต้องดูว่า IO นั้นมีจำนวนเท่าใด ฉันจะไม่คิดว่ามันเป็นเครือข่าย (เว้นแต่ว่าคุณอยู่บนลิงค์ครึ่งดูเพล็กซ์ 10mbps แต่มันคุ้มค่าที่จะตรวจสอบสวิตช์ในกรณีที่ระบบตรวจจับอัตโนมัติทำงานไม่ถูกต้อง)

นั่นทำให้ดิสก์ IO ซึ่งเป็นปัจจัยใหญ่โดยเฉพาะกับ VPS ใช้ sar หรือ iostat เพื่อดูดิสก์จากนั้น Google จะค้นหารายละเอียดเพิ่มเติมได้อย่างไรหากดิสก์ของคุณถูกใช้งานอย่างหนัก


ใช่เครือข่ายไม่ใช่ปัญหา - เมื่อใช้ ab จากเซิร์ฟเวอร์ท้องถิ่นประสิทธิภาพจะเหมือนกัน ฉันได้ตรวจสอบเวลา iowait - มีค่าต่ำกว่า 0,01% - โดยทั่วไปทุกอย่างอยู่ในแคชของดิสก์และไม่มีดิสก์บันทึกที่เกี่ยวข้องในการประมวลผลคำขอ (บันทึกทั้งหมดถูกปิดใช้งาน)
BarsMonster

1

ฉันจะมองเข้าไปในแคชด้วยNginx ( memcached ) หรือวานิช

อย่างน้อยที่สุดคุณควรเซิร์ฟเวอร์ไฟล์คงที่ด้วย Nginx เช่น SaveTheRbtz กล่าว


นี่คือหน้าเว็บแบบไดนามิกดังนั้นฉันไม่ต้องการแคชพวกเขา
BarsMonster

1
memcached ไม่ใช่แอพแคชแบบดั้งเดิมและสามารถทำงานได้อย่างมหัศจรรย์สำหรับหน้าเว็บแบบไดนามิก มันตั้งอยู่ระหว่าง DB และแอปของคุณ แอพที่คุณสืบค้นครั้งแรก memcached สำหรับวัตถุถ้ามันไม่ได้มีก็จะโหลดจากฐานข้อมูล ผลกระทบสุทธิคือคุณกำลังใช้ RAM เพื่อให้บริการการร้องขอ DB ของคุณมากกว่าการเก็บข้อมูลถาวรบน DB
jamieb

Memcache สามารถใช้กับ nginx ซึ่งเป็นคุณสมบัติที่รู้จัก ไม่ได้ใช้ที่เก็บข้อมูลที่ช้าลง แต่ทั้งหมดอยู่ในแคชแบบสอบถามใน MySQL
BarsMonster

Memcached และแคชแบบสอบถามของ MySQL นั้นไม่สามารถเปรียบเทียบกันได้ พวกเขาไม่ได้ทำสิ่งเดียวกัน คุณค่อนข้างรวดเร็วที่จะทำทุกข้อเสนอแนะที่โพสต์ไว้ที่นี่โดยไม่ต้องไปทำความเข้าใจ ฉันขอแนะนำให้คุณเป็นคนใจกว้างมากขึ้น
jamieb

ฉันเข้าใจความแตกต่างระหว่าง memcached และแคชแบบสอบถาม MySQL อย่างชัดเจน แต่เนื่องจากความจริงที่ว่าทุกอย่างอยู่ในแคชของคิวรีที่มีอัตราการเข้าชม 100% ฉันจะไม่เรียกมันว่า "พื้นที่จัดเก็บข้อมูลช้า" คำตอบเดิมของเมื่อวานนี้เกี่ยวกับการใช้ NginX + Memcached ซึ่งเป็นสถานการณ์ที่ค่อนข้างบ่อยในการแคชทั้งหน้า การแคชวัตถุแต่ละชิ้นเป็นอีกสถานการณ์หนึ่งที่แตกต่างกันโดยสิ้นเชิง ในขณะที่ใช้ memcached ที่หน้า MySQL อยู่บนโต๊ะฉันกำลังคิดว่าจะได้น้ำผลไม้มากขึ้นโดยที่ไม่ต้องใช้ตอนนี้ (เพราะจะต้องมีการเปลี่ยนแปลงรหัสเล็กน้อย
BarsMonster

1

ดูเหมือนว่าเซิร์ฟเวอร์จะไม่มีปัญหาบางทีตัวสร้างโหลดอาจเป็น ลองรันมันบนเครื่องหลายเครื่อง


ประสิทธิภาพจะเหมือนกันแม้ว่าฉันจะเรียกใช้จากเซิร์ฟเวอร์เอง ไม่ว่าการเชื่อมต่อพร้อมกันของมนูจะเกิดขึ้นได้อย่างไร - 10 หรือ 50 การทดสอบโหลดทำผ่าน ab -c 10 -t 10
BarsMonster

1

ฟังดูเหมือนว่าคุณอาจเชื่อมต่อกับจำนวนการเชื่อมต่อสูงสุดที่ Apache อนุญาตให้ดูการกำหนดค่า Apache ของคุณ การเพิ่มขีด จำกัด เซิร์ฟเวอร์และไคลเอนต์สูงสุดควรช่วยหากคุณไม่ได้ถูก จำกัด ด้วยขีด จำกัด อื่นเช่น I / O หรือหน่วยความจำ ดูค่าปัจจุบันสำหรับ mpm_prefork_module หรือ mpm_worker_module และปรับเปลี่ยนตามความต้องการของคุณ

ServerLimit 512
MaxClients 512

ฉันจำเป็นต้องใช้สิ่งนี้หรือไม่หากฉันมี nginx ต่อหน้า apache2 ดังนั้นฉันจึงเชื่อว่าไม่มีอะไรมากกว่าการมีแกนประมวลผลทางกายภาพ * 2 กระบวนการ Apache2 ....
BarsMonster

เพิ่งยืนยันสิ่งนี้ การเพิ่มจำนวนกระบวนการ Apache2 จาก 4 เป็น 16 ไม่ได้ปรับปรุงประสิทธิภาพเลย (ลดลง 0.5%) การเพิ่มจำนวนพนักงาน nginx เป็น 2 หรือ 4 ไม่ได้ปรับปรุงอะไรเลย
BarsMonster

1
หากข้อมูลของคุณค่อนข้างคงที่นั่นคือไม่อัปเดตทุก ๆ หน้าโหลดคุณสามารถเพิ่ม query_cache ของคุณ MySQL จะยึดชุดผลลัพธ์ไว้และดึงออกมาจากหน่วยความจำ อย่างไรก็ตามหากตารางที่ถูกแคชได้รับการเขียนใด ๆ ในช่วงเวลาดังกล่าวจะทำให้แคชใช้ไม่ได้ (แม้ว่าข้อมูลจะไม่ได้รับผลกระทบ) ทำให้สูญเสียความทรงจำ
Erik Giberti

ตอนนี้ฉันเห็นอัตราส่วนการแคชแคช 100% และ MySQL ยังคงรู้สึกช้า ...
BarsMonster

1
เพิ่ม skip-name-resol ให้กับไฟล์ปรับแต่ง MySQL ของคุณ ที่จะบันทึกการค้นหา DNS ในทุกการเชื่อมต่อกับเซิร์ฟเวอร์ ข้อเสียเปรียบที่นี่คือการเชื่อมต่อทั้งหมดจะต้องถูกล็อคโดย IP (สมมติว่าคุณไม่ได้ใช้ '%') หาก SQL อยู่บนเซิร์ฟเวอร์เดียวกันและไม่จำเป็นต้องเข้าถึงที่อื่นนอกจาก localhost คุณสามารถเพิ่มระบบเครือข่ายข้ามเพื่อกำจัดสแต็ก TCP / IP ทั้งหมดได้ อย่างไรก็ตามฉันคิดว่าคอขวดคือ Apache
Erik Giberti

0

ภาระนี้สร้างขึ้นโดยเครื่องมือหรือโหลดจริงหรือไม่?

คุณอาจต้องการตรวจสอบ memcached ฉันพบปัญหาในอัตราการเชื่อมต่อที่สูงซึ่งก่อให้เกิดความล่าช้าในแอปพลิเคชัน

หากใช้ตัวสร้างโหลดคุณจะได้อะไรเมื่อกดหน้าสแตติกเล็ก ๆ

ในระหว่างการโหลดคุณอาจต้องการตรวจสอบสแต็กเครือข่ายสำหรับเงื่อนไข TIME_WAIT บางทีคุณอาจกรอกคิวการเชื่อมต่อของคุณ

มีเหตุผลมากกว่า 100 รายการและรายการที่คุณสามารถดูได้ แต่หากไม่มีข้อมูลเพิ่มเติมฉันแค่ทิ้งการเดาไว้ที่จุดนี้


ผ่านการทดสอบผ่าน ab-c 10 -t 10 URL ที่ฉันทำการเปรียบเทียบจากเซิร์ฟเวอร์เองดังนั้นเครือข่ายไม่ควรเป็นปัญหา ฉันโพสต์มาตรฐานเพิ่มเติมตามคำขอของคุณ
BarsMonster

ฉันจะไม่ใช้ความพยายามปรับจูนกับ ab มากเกินไป คุณอาจพบว่ามันแปลได้ไม่ดีเท่าการแสดงในโลกแห่งความเป็นจริง สิ่งที่คุณอาจต้องทำคือตัดแอพของคุณและทดสอบแต่ละองค์ประกอบ ตัวอย่างเช่นกดเซิร์ฟเวอร์ apache โดยตรงด้วยหน้าสแตติกขนาดเล็กมาก สิ่งนี้จะช่วยให้คุณทราบถึงจำนวนคำขอสูงสุด / วินาทีในแบ็กเอนด์ วาง nginx ไว้ด้านหน้าทดสอบไฟล์แบ็กเอนด์เดิมอีกครั้ง จากนั้นทดสอบด้วยหน้าพิมพ์ php "hello world" ที่เรียบง่ายบางครั้งเลเยอร์ทั้งหมดสามารถปกปิดบางสิ่งได้ง่าย นอกจากนี้ดูการเชื่อมต่อระหว่างการทดสอบ ตรวจสอบให้แน่ใจว่าสแต็กเครือข่ายของคุณไม่เต็ม
jeffatrackaid

ฉันทำเกณฑ์มาตรฐานเหล่านี้เมื่อวานนี้และพวกเขาอยู่ในคำอธิบายคำถามต้นฉบับที่อัปเดตแล้ว นอกจากนี้ยังมีการทดสอบบน localhost ดังนั้นเครือข่ายจึงไม่เป็นปัญหา
BarsMonster

เครือข่ายอาจเป็นปัญหาแม้ว่าจะทำในโฮสต์ท้องถิ่น ไม่น่าเป็นไปได้ในกรณีของคุณ แต่อาจทำให้เกิดปัญหา ก่อนนี้คุณจะมีขีด จำกัด สูงสุด ~ 450 req / วินาทีด้วยการตั้งค่า PHP ปัจจุบันของคุณ ขั้นตอนต่อไปคือการวางสายฐานข้อมูลและดูว่ามีการเปลี่ยนแปลงอย่างไร ฉันชอบที่จะแยกมันออกจากกันเมื่อทำการจูนระดับสูงเพราะมันสามารถช่วยให้คุณระบุเลเยอร์ที่ทำให้เกิดปัญหาได้มากที่สุด
jeffatrackaid

-1

99% เปอร์เซ็นต์ของปัญหาเวลาเช่นนี้จะติดตามกลับไปยังฐานข้อมูล ตรวจสอบให้แน่ใจว่าดัชนีการกดปุ่มของคุณเป็นอันดับแรก หากวิธีนี้ไม่ได้ผลให้เริ่มการแคชทุกอย่างที่คุณทำได้


มันเป็นดัชนีทั้งหมดและอย่างที่ฉันบอกไปมันยังกดปุ่ม MySQL แบบสอบถามแคชใน 100% ของกรณี
BarsMonster

-1

ฉันขอแนะนำให้คุณใช้ (ถ้าเป็นไปได้) ตัวรวบรวมการเชื่อมต่อเพื่อให้ฐานข้อมูลเชื่อมต่อกับเว็บแอปพลิเคชันของคุณ (ไม่จำเป็นต้องเชื่อมต่อใหม่ในแต่ละคำขอ) ที่สามารถสร้างความแตกต่างของความเร็วอย่างมาก

นอกจากนี้ลองวิเคราะห์ข้อความค้นหาของคุณทั้งหมดด้วยอธิบาย (และทำไมไม่โพรไฟล์แบบสอบถามของคุณด้วย SHOW PROFILE?)


แบบสอบถามทั้งหมดใช้ดัชนี ใช้การเชื่อมต่อ MySQL
BarsMonster
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.