กลยุทธ์สำหรับการใช้ PHP ในไซต์ที่มีโหลดสูง


242

ก่อนที่คุณจะตอบคำถามนี้ฉันไม่เคยพัฒนาอะไรที่ได้รับความนิยมมากพอที่จะทำให้เซิร์ฟเวอร์มีความเร็วสูง ปฏิบัติกับฉันเหมือนถอนหายใจคนต่างด้าวที่เพิ่งลงจอดบนโลกแม้ว่าจะเป็นคนที่รู้ PHP และเทคนิคการเพิ่มประสิทธิภาพเล็กน้อย


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

ฐานข้อมูล

ตอนนี้ฉันวางแผนจะใช้ฟีเจอร์ MySQLi ใน PHP5 อย่างไรก็ตามฉันจะตั้งค่าฐานข้อมูลที่เกี่ยวข้องกับผู้ใช้และเนื้อหาได้อย่างไร ฉันต้องการฐานข้อมูลหลายฐานข้อมูลจริงหรือไม่? ในขณะนี้ทุกสิ่งต่างก็วนเวียนอยู่ในฐานข้อมูลเดียว - แม้ว่าฉันได้พิจารณากระจายข้อมูลผู้ใช้ไปที่หนึ่ง แต่เนื้อหาจริงไปยังอีกเนื้อหาหนึ่ง เหตุผลของฉันคือการส่งแบบสอบถามไปยังฐานข้อมูลที่แตกต่างกันจะทำให้ภาระในการโหลดเป็นฐานข้อมูลหนึ่ง = 3 โหลดซอร์ส สิ่งนี้จะยังมีผลหรือไม่หากอยู่บนเซิร์ฟเวอร์เดียวกันทั้งหมด

เก็บเอาไว้

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

คำถามของฉันเกี่ยวกับเรื่องนี้:

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

ในที่สุด

ไม่มีใครมีเคล็ดลับ / คำแนะนำสำหรับใช้เว็บไซต์โหลดสูงใน PHP ฉันค่อนข้างแน่ใจว่ามันเป็นภาษาที่ใช้งานได้ - Facebook และ Yahoo! ให้ความสำคัญมาก - แต่มีประสบการณ์ใดบ้างที่ฉันควรระวัง?


9
3.5 ปีต่อมาและฉันไม่สามารถแม้แต่จะจำสิ่งที่ฉันกำลังทำงานอยู่บนผมอยากที่จะรู้ว่าสิ่งที่ผมคิดว่าเป็นเช่นนั้นเย็นมากเกินไป :)
รอสส์

8
ให้นี่เป็นบทเรียนสำหรับคุณเกี่ยวกับการปรับให้เหมาะสมก่อนวัยเรียน :)
Rimu Atkinson

คำตอบ:


89

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

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

และอย่าลืมว่าคุณไม่ได้ปรับสัดส่วน ไซต์ที่จัดการ 10req / s จะต้องมีการเปลี่ยนแปลงเพื่อรองรับ 1,000req / s และถ้าคุณโชคดีพอที่จะต้องสนับสนุน 10,000req / s สถาปัตยกรรมของคุณอาจดูแตกต่างอย่างสิ้นเชิงเช่นกัน

ฐานข้อมูล

  • อย่าใช้ MySQLi - PDOเป็นเลเยอร์การเข้าถึงฐานข้อมูล 'ทันสมัย' OO คุณลักษณะที่สำคัญที่สุดที่จะใช้คือตัวยึดตำแหน่งในแบบสอบถามของคุณ มันฉลาดพอที่จะใช้การเตรียมฝั่งเซิร์ฟเวอร์และการเพิ่มประสิทธิภาพอื่น ๆ สำหรับคุณเช่นกัน
  • คุณอาจไม่ต้องการแยกฐานข้อมูลของคุณในตอนนี้ หากคุณพบว่าฐานข้อมูลเดียวไม่ได้ตัดมีหลายเทคนิคในการขยายขนาดขึ้นอยู่กับแอปของคุณ โดยทั่วไปการทำซ้ำไปยังเซิร์ฟเวอร์เพิ่มเติมจะทำงานได้ดีถ้าคุณอ่านมากกว่าเขียน Sharding เป็นเทคนิคในการแบ่งข้อมูลของคุณผ่านเครื่องหลาย ๆ เครื่อง

เก็บเอาไว้

  • คุณอาจไม่ต้องการแคชในฐานข้อมูลของคุณ โดยทั่วไปแล้วฐานข้อมูลเป็นคอขวดของคุณดังนั้นการเพิ่ม IO ให้มากขึ้นนั้นเป็นสิ่งที่ไม่ดี มี PHP หลายแคชที่ทำสิ่งที่คล้ายกันเช่นAPCและ Zend
  • วัดระบบของคุณด้วยการแคชเปิดและปิด ฉันพนันว่าแคชของคุณหนักกว่าการแสดงหน้าเว็บให้ตรง
  • หากใช้เวลานานในการสร้างความคิดเห็นและข้อมูลบทความของคุณจาก db ให้รวมmemcacheเข้ากับระบบของคุณ คุณสามารถแคชผลลัพธ์แบบสอบถามและเก็บไว้ในอินสแตนซ์ memcached สิ่งสำคัญคือต้องจำไว้ว่าการดึงข้อมูลจาก memcache จะต้องเร็วกว่าการรวบรวมจากฐานข้อมูลเพื่อดูประโยชน์ใด ๆ
  • หากบทความของคุณไม่ได้เป็นแบบไดนามิกหรือคุณมีการเปลี่ยนแปลงแบบไดนามิกอย่างง่ายหลังจากที่สร้างขึ้นแล้วให้ลองเขียน html หรือ php ลงในดิสก์ คุณอาจมีหน้า index.php ที่ดูบนดิสก์สำหรับบทความหากมีอยู่มันจะส่งไปยังไคลเอนต์ หากไม่ใช่จะสร้างบทความเขียนลงดิสก์และส่งไปยังลูกค้า การลบไฟล์ออกจากดิสก์จะทำให้หน้าเขียนซ้ำ หากความคิดเห็นถูกเพิ่มเข้าไปในบทความลบสำเนาที่เก็บไว้ - มันจะถูกสร้างใหม่

10
@ เขียนลงดิสก์ คุณสามารถทิ้ง index.php และปล่อยให้ Apache ทำงานให้คุณได้ดังนั้น index.php จะถูกเรียกใช้เฉพาะในกรณีที่ไม่มีเส้นทาง คุณต้องการใช้ mode_rewrite สำหรับสิ่งนี้
troelskn

5
-1, PDO ช้ากว่า MySQLi หรือแม้แต่ส่วนขยาย MySQL อย่างมีนัยสำคัญ
Alix Axel

4
PDO นั้นช้ากว่า mysqli มากและใช้งานไม่ได้กับคำค้นหาซ้อนสำหรับฉัน Mysqli ยังสนับสนุนการเตรียมเซิร์ฟเวอร์และพารามิเตอร์ที่ถูกผูกไว้เช่นเดียวกับ PDO
Daren Schwenke

5
ฉันไม่อยากจะเชื่อเลยว่านี่เป็นคำตอบที่ได้รับการยอมรับ มันไม่ดีมาก
symcbean

1
เกี่ยวกับ: แคช - รูปภาพ, css, htm และ js จะช่วยปิดคุกกี้ในภาพด้วย!
Talvi Watia

61

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

SCHEMA ก่อนอื่นให้ลดระดับสคีมาของคุณ ซึ่งหมายความว่าแทนที่จะมีหลายตารางสัมพันธ์คุณควรเลือกที่จะมีตารางขนาดใหญ่หนึ่งตารางแทน โดยทั่วไปแล้วการรวมเป็นทรัพยากรของ DB ที่มีค่าเพราะการเตรียมและการเรียงหลาย ๆ ครั้งจะทำให้ดิสก์ I / O ถูกเบิร์น หลีกเลี่ยงพวกเขาเมื่อคุณสามารถ

การแลกเปลี่ยนที่นี่คือคุณจะจัดเก็บ / ดึงข้อมูลซ้ำซ้อน แต่เป็นที่ยอมรับได้เนื่องจากข้อมูลและแบนด์วิดธ์ภายในกรงนั้นราคาถูกมาก (ดิสก์ที่ใหญ่กว่า) ในขณะที่การเตรียม I / O หลายรายการนั้นเป็นคำสั่งที่มีราคาแพงกว่า .

การจัดทำดัชนี ให้แน่ใจว่าคำสั่งของคุณใช้ดัชนีอย่างน้อยหนึ่ง แต่ระวังดัชนีนั้นจะเสียค่าใช้จ่ายหากคุณเขียนหรืออัพเดทบ่อยๆ มีเทคนิคการทดลองบางอย่างเพื่อหลีกเลี่ยงปัญหานี้

คุณสามารถลองเพิ่มคอลัมน์เพิ่มเติมที่ไม่ได้จัดทำดัชนีซึ่งทำงานแบบขนานกับคอลัมน์ของคุณที่ได้รับการจัดทำดัชนี จากนั้นคุณสามารถมีกระบวนการออฟไลน์ที่เขียนคอลัมน์ที่ไม่ได้จัดทำดัชนีไว้เหนือคอลัมน์ที่จัดทำดัชนีเป็นชุด วิธีนี้คุณสามารถควบคุมได้ดีขึ้นเมื่อ mySQL จะต้องคำนวณดัชนีอีกครั้ง

หลีกเลี่ยงการคำนวณที่คำนวณเช่นกาฬโรค ถ้าคุณต้องคำนวณแบบสอบถามลองทำสิ่งนี้ครั้งเดียวในเวลาเขียน

แคช ฉันขอแนะนำ Memcached ได้รับการพิสูจน์โดยผู้เล่นที่ยิ่งใหญ่ที่สุดในสแต็ค PHP (Facebook) และมีความยืดหยุ่นสูง มีสองวิธีในการทำเช่นนี้วิธีหนึ่งคือการแคชในเลเยอร์ DB ของคุณและอีกวิธีคือการแคชในเลเยอร์ตรรกะทางธุรกิจของคุณ

ตัวเลือกเลเยอร์ DB จะต้องมีการแคชผลลัพธ์ของแบบสอบถามที่ดึงมาจากฐานข้อมูล คุณสามารถแฮชคิวรี่ SQL ของคุณโดยใช้ md5 () และใช้มันเป็นคีย์การค้นหาก่อนไปที่ฐานข้อมูล ข้อดีของมันคือมันใช้งานง่าย ข้อเสีย (ขึ้นอยู่กับการใช้งาน) คือคุณเสียความยืดหยุ่นเนื่องจากคุณยังคงใช้แคชทั้งหมดเหมือนกันกับการหมดอายุของแคช

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

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

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

ข้อเสียคืออาจยากที่จะรวบรวมข้อมูลจากหลาย ๆ เศษ แต่คุณสามารถกำหนดวิธีการของคุณเช่นกัน

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


9
+1 ลงมือนี่ควรเป็นคำตอบที่ยอมรับได้ เป็นที่น่าสนใจว่าทุกสิ่งที่ฉันเคยอ่านเกี่ยวกับการสร้างฐานข้อมูลมักจะพูดว่า "ทำให้ข้อมูลทั้งหมดเป็นปกติมากที่สุด" โดยไม่ต้องพูดถึงประสิทธิภาพการทำงานของการเข้าร่วม ฉันรู้สึกอย่างสังหรณ์ใจเสมอว่าการเข้าร่วม (โดยเฉพาะหลายรายการ) เพิ่มค่าใช้จ่ายจำนวนมาก แต่ไม่เคยได้ยินใครพูดเลยว่ามันชัดเจนจนถึงตอนนี้ ฉันหวังว่าฉันจะเข้าใจสิ่งที่คุณพูดถึงเกี่ยวกับการควบคุมได้ดีขึ้นเมื่อ MySQL คำนวณดัชนีดูเหมือนว่าแฮ็คที่น่าสนใจมาก
Evan Plaice

Data sharding มีความสำคัญสำหรับฐานข้อมูลที่มีขนาดใหญ่เกินไป Google (บริษัท ที่ไม่ใช่เครื่องมือค้นหา) มีหลายสิ่งที่น่าสนใจที่จะพูดเกี่ยวกับการใช้แผนการแบ่งส่วน การประมวลผลแบบออฟไลน์นั้นมีขนาดใหญ่เช่นกันเมื่อ จำกัด จำนวนการเขียนฐานข้อมูล (และ จำกัด จำนวนการคำนวณดัชนีตารางใหม่) ฉันเห็นบล็อกจำนวนมาก (และฉันคิดว่าแม้กระทั่ง Stack Overflow) ใช้เทคนิคนี้สำหรับระบบความคิดเห็น / ข้อเสนอแนะที่ผู้ใช้สร้างขึ้น
Evan Plaice

1
ขอบคุณสำหรับความคิดเห็น เป็นเรื่องที่น่าแปลกใจที่บางคนโต้แย้งว่าการทำโปรไฟล์โค้ดระดับกลางเมื่อใช้เวลาดำเนินการ VAST เป็นจำนวนมากใน data I / O หรือ I / O ของไคลเอนต์ - เซิร์ฟเวอร์ การเพิ่มประสิทธิภาพที่ซับซ้อน ubber ประหยัด 20% เวลาดำเนินการของกระบวนการ PHP ที่ใช้เวลา 40 มิลลิวินาทีนั้นไม่มีจุดหมายเมื่อเทียบกับการประหยัด 5% ง่ายๆจากการสืบค้นฐานข้อมูล 1s
thesmart

42

ฉันได้ทำงานกับเว็บไซต์บางแห่งที่ได้รับความนิยมนับล้านครั้ง / เดือนโดย PHP และ MySQL นี่คือพื้นฐานบางอย่าง:

  1. แคชแคชแคช การแคชเป็นวิธีที่ง่ายและมีประสิทธิภาพที่สุดในการลดโหลดบนเว็บเซิร์ฟเวอร์และฐานข้อมูลของคุณ เนื้อหาหน้าแคชแบบสอบถามการคำนวณราคาแพงสิ่งที่ I / O ผูกพัน Memcache นั้นตายง่ายและมีประสิทธิภาพ
  2. ใช้เซิร์ฟเวอร์หลายเครื่องเมื่อคุณออกสูงสุด คุณสามารถมีเว็บเซิร์ฟเวอร์ได้หลายเครื่องและเซิร์ฟเวอร์ฐานข้อมูลหลายตัว (พร้อมการจำลองแบบ)
  3. ลด # คำขอโดยรวมให้กับเว็บเซิร์ฟเวอร์ของคุณ สิ่งนี้มีผลต่อการแคช JS, CSS และรูปภาพโดยใช้ส่วนหัวที่หมดอายุ นอกจากนี้คุณยังสามารถย้ายเนื้อหาสแตติกของคุณไปยัง CDN ซึ่งจะเพิ่มความเร็วให้ผู้ใช้ของคุณ
  4. วัดและมาตรฐาน เรียกใช้ Nagios บนเครื่องที่ใช้งานจริงของคุณและทดสอบการโหลดบนเซิร์ฟเวอร์ dev / qa ของคุณ คุณต้องรู้ว่าเซิร์ฟเวอร์ของคุณจะติดไฟเมื่อไหร่เพื่อให้สามารถป้องกันได้

ฉันขอแนะนำให้อ่าน สร้างเว็บไซต์ที่ปรับขนาดได้ซึ่งเขียนโดยหนึ่งในวิศวกร Flickr และเป็นข้อมูลอ้างอิงที่ดี

ลองดูโพสต์บล็อกของฉันเกี่ยวกับความสามารถในการปรับขนาดได้เช่นกัน แต่ก็มีลิงก์จำนวนมากที่นำเสนอเกี่ยวกับการปรับขนาดด้วยหลายภาษาและแพลตฟอร์ม: http://www.ryandoherty.net/2008/07/13/unicorns-and-scalability/


1
+1 มีข้อมูลที่ดีมากมายที่นี่ ฉันค้นคว้าเพิ่มเติมเกี่ยวกับหัวข้อนี้เมื่อเร็ว ๆ นี้และคำตอบของคุณสอดคล้องกับทุกสิ่งที่ฉันอ่าน Memcache, caching, CDN สำหรับเนื้อหาแบบสแตติกลดการร้องขอ ทุกสิ่งที่ดี ฉันจะเพิ่มสร้างแฮชบนไฟล์เนื้อหาแบบคงที่ (ถ้าอยู่ด้านหลัง CDN / แคช) ฝั่งเซิร์ฟเวอร์ดังนั้นไฟล์ที่อัปเดตจะมีลายเซ็นที่ไม่ซ้ำกันในแคช นอกจากนี้ให้รวมไฟล์ซอร์สแบบคงที่ (css, javascript) เข้าด้วยกันทันที (และแคชกับไฟล์แฮชของชื่อไฟล์) เพื่อลดการร้องขอ นอกจากนี้ยังสร้าง thumbs แบบไดนามิก (และเก็บไว้ในแคช)
Evan Plaice

Google ได้สร้างโมดูล apache ชื่อว่า mod_pagespeed ซึ่งสามารถจัดการการต่อข้อมูลไฟล์การลดขนาดการเปลี่ยนชื่อไฟล์เพื่อรวมแฮช ฯลฯ สำหรับเนื้อหาสแตติกทั้งหมด มันควรจะเพิ่มค่าใช้จ่ายในการประมวลผลเพียงเล็กน้อยไปยังเซิร์ฟเวอร์ในตอนแรกจนกว่าแคช (และ CDN) จะบรรจุด้วยเนื้อหาส่วนใหญ่ นอกจากนี้เพื่อความปลอดภัยโดยทั่วไปเป็นความคิดที่ดีที่จะวางตารางที่สามารถเข้าถึงได้แบบสาธารณะ (ผู้ใช้) ในฐานข้อมูลเดียวกันกับตารางมากกว่าจัดการแบ็คเอนด์ (ถ้าด้วยเหตุผลบางประการ
Evan Plaice

39

เรื่อง PDO / MySQLi / MySQLND

แอทแกรี่

คุณไม่สามารถพูดว่า "ไม่ใช้ MySQLi" เพราะพวกเขามีเป้าหมายที่แตกต่างกัน PDO นั้นเกือบจะเป็นเลเยอร์ที่เป็นนามธรรม (แม้ว่ามันจะไม่ได้เป็นจริง) และถูกออกแบบมาเพื่อให้ง่ายต่อการใช้ผลิตภัณฑ์ฐานข้อมูลหลายตัว มันผิดที่จะบอกว่า PDO เป็นเลเยอร์การเข้าถึงที่ทันสมัยในบริบทของการเปรียบเทียบกับ MySQLi เพราะคำแถลงของคุณบอกเป็นนัยว่าการก้าวหน้านั้นเป็น mysql -> mysqli -> PDO ซึ่งไม่เป็นเช่นนั้น

ตัวเลือกระหว่าง MySQLi และ PDO นั้นง่าย - ถ้าคุณต้องการสนับสนุนผลิตภัณฑ์ฐานข้อมูลหลายตัวคุณก็ใช้ PDO หากคุณเพิ่งใช้ MySQL คุณสามารถเลือกระหว่าง PDO และ MySQLi

แล้วทำไมคุณถึงเลือก MySQLi มากกว่า PDO ดูด้านล่าง ...

@ross

คุณถูกต้องเกี่ยวกับ MySQLnd ซึ่งเป็นไลบรารี่ระดับภาษาหลักของ MySQL แต่มันไม่ใช่สิ่งทดแทนสำหรับ MySQLi MySQLi (เช่นเดียวกับ PDO) ยังคงเป็นวิธีที่คุณโต้ตอบกับ MySQL ผ่านโค้ด PHP ของคุณ ทั้งสองใช้ libmysql เป็นไคลเอนต์ C ที่อยู่เบื้องหลังโค้ด PHP ปัญหาคือ libmysql อยู่นอกเอ็นจิน PHP หลักและนั่นคือที่ mysqlnd เข้ามานั่นคือเนทีฟไดร์เวอร์ที่ใช้ประโยชน์จาก PHP หลักภายในเพื่อเพิ่มประสิทธิภาพโดยเฉพาะเมื่อมีการใช้หน่วยความจำ

MySQLnd ได้รับการพัฒนาโดยตัว MySQL เองและเพิ่งจะลงสู่สาขา PHP 5.3 ซึ่งอยู่ในการทดสอบ RC พร้อมสำหรับการเปิดตัวในปีนี้ จากนั้นคุณจะสามารถใช้ MySQL และกับ MySQLi แต่ไม่สามารถใช้กับ PDO ได้ สิ่งนี้จะทำให้ MySQLi เพิ่มประสิทธิภาพในหลาย ๆ ด้าน (ไม่ใช่ทั้งหมด) และจะเป็นตัวเลือกที่ดีที่สุดสำหรับการโต้ตอบกับ MySQL ถ้าคุณไม่ต้องการสิ่งที่เป็นนามธรรมเช่นความสามารถของ PDO

ที่กล่าวว่าขณะนี้ MySQL และตอนนี้มีอยู่ใน PHP 5.3สำหรับ PDO และคุณสามารถได้รับประโยชน์จากการปรับปรุงประสิทธิภาพจาก ND เป็น PDO อย่างไรก็ตาม PDO ยังคงเป็นเลเยอร์ฐานข้อมูลทั่วไปและดังนั้นจึงไม่น่าจะได้รับประโยชน์มากนักจาก เพิ่มประสิทธิภาพในการ ND เป็น MySQLi กระป๋อง

การวัดประสิทธิภาพที่เป็นประโยชน์บางอย่างสามารถพบได้ที่นี่แม้ว่าจะมาจากปี 2549 คุณต้องระวังสิ่งต่างๆเช่นตัวเลือกนี้

มีการพิจารณาจำนวนมากที่ต้องพิจารณาเมื่อทำการตัดสินใจระหว่าง MySQLi และ PDO ในความเป็นจริงมันจะไม่สำคัญจนกว่าคุณจะได้รับหมายเลขคำขอที่สูงขึ้น rediculously และในกรณีนี้คุณควรใช้ส่วนขยายที่ได้รับการออกแบบมาโดยเฉพาะสำหรับ MySQL แทนที่จะเป็นสิ่งที่เป็นนามธรรมและให้ไดรเวอร์ MySQL .

มันไม่ได้เป็นเรื่องง่ายที่ดีที่สุดเพราะแต่ละคนมีข้อดีและข้อเสีย คุณต้องอ่านลิงก์ที่ฉันให้และตัดสินใจด้วยตัวคุณเองจากนั้นทดสอบและค้นหา ฉันใช้ PDO ในโครงการที่ผ่านมาและเป็นส่วนเสริมที่ดี แต่ตัวเลือกของฉันสำหรับประสิทธิภาพที่แท้จริงคือ MySQLi พร้อมตัวเลือก MySQLND ใหม่ที่คอมไพล์ (เมื่อ PHP 5.3 เปิดตัว)


6
ฉันเปลี่ยนจาก PDO เป็น mysqli และข้อความค้นหาทั่วไปเริ่มทำงานได้เร็วขึ้น 2 เท่า
serg

5
@ serg: สนใจที่จะโพสต์การทดสอบเพื่อยืนยันสิ่งนี้หรือไม่เพราะฉันสงสัยอย่างจริงจังว่าเพียงแค่เปลี่ยนจาก PDO เป็น mysqli จะช่วยเพิ่มความเร็วให้กับคุณ
Stann

23

ทั่วไป

  • อย่าพยายามปรับให้เหมาะสมก่อนที่คุณจะเริ่มเห็นภาระของโลกแห่งความจริง คุณอาจเดาถูก แต่ถ้าไม่ทำคุณเสียเวลา
  • ใช้jmeter , xdebugหรือเครื่องมืออื่นเพื่อวัดประสิทธิภาพเว็บไซต์
  • หากการโหลดเริ่มเป็นปัญหาวัตถุหรือการแคชข้อมูลอาจมีส่วนเกี่ยวข้องดังนั้นโดยทั่วไปควรอ่านตัวเลือกการแคช (memcached, ตัวเลือกการแคช MySQL)

รหัส

  • โปรไฟล์รหัสของคุณเพื่อให้คุณทราบว่าเป็นคอขวดและไม่ว่าจะเป็นในรหัสหรือฐานข้อมูล

ฐานข้อมูล

  • ใช้MYSQLiหากการพกพาไปยังฐานข้อมูลอื่นไม่สำคัญPDOอย่างอื่น
  • หากเกณฑ์มาตรฐานเปิดเผยว่าฐานข้อมูลเป็นปัญหาให้ตรวจสอบแบบสอบถามก่อนที่คุณจะเริ่มแคช ใช้อธิบายเพื่อดูว่าคิวรีของคุณอยู่ที่ไหนช้าลง
  • หลังจากแบบสอบถามได้รับการปรับให้เหมาะสมและฐานข้อมูลถูกแคชอย่างใดคุณอาจต้องการใช้หลายฐานข้อมูล การเรพลิเคตไปยังเซิร์ฟเวอร์หลายเครื่องหรือการแบ่ง (การแบ่งข้อมูลผ่านหลายฐานข้อมูล / เซิร์ฟเวอร์) อาจเหมาะสมขึ้นอยู่กับข้อมูลแบบสอบถามและชนิดของพฤติกรรมการอ่าน / เขียน

เก็บเอาไว้

  • มีการเขียนมากมายในโค้ดแคชวัตถุและข้อมูล เงยหน้าขึ้นมองบทความเกี่ยวกับAPC , Zend Optimizer , memcached , QuickCache , JPCache ทำสิ่งนี้ก่อนที่คุณจะต้องการจริงๆและคุณจะมีความกังวลน้อยลงเกี่ยวกับการเริ่มต้นที่ไม่เพิ่มประสิทธิภาพ
  • APC และ Zend Optimizer เป็นแคช opcode ซึ่งจะเพิ่มความเร็วโค้ด PHP โดยหลีกเลี่ยงการแยกวิเคราะห์และรวบรวมรหัสใหม่ โดยทั่วไปติดตั้งง่ายคุ้มค่ากับการเริ่มต้น
  • Memcached เป็นแคชทั่วไปที่คุณสามารถใช้เพื่อแคชแบบสอบถามฟังก์ชัน PHP หรือวัตถุหรือทั้งหน้า รหัสจะต้องเขียนโดยเฉพาะเพื่อใช้งานซึ่งอาจเป็นกระบวนการที่เกี่ยวข้องหากไม่มีจุดกลางในการจัดการการสร้างอัปเดตและลบวัตถุแคช
  • QuickCache และ JPCache เป็นไฟล์แคชมิฉะนั้นคล้ายกับ Memcached แนวคิดพื้นฐานนั้นง่าย แต่ก็ต้องใช้รหัสและง่ายขึ้นด้วยจุดศูนย์กลางของการสร้างอัปเดตและลบ

เบ็ดเตล็ด

  • พิจารณาเว็บเซิร์ฟเวอร์ทางเลือกสำหรับการโหลดสูง เซิร์ฟเวอร์เช่นlighthttpและnginxสามารถจัดการปริมาณข้อมูลจำนวนมากในหน่วยความจำน้อยกว่าApacheมากถ้าคุณสามารถเสียสละพลังและความยืดหยุ่นของ Apache (หรือถ้าคุณไม่ต้องการสิ่งเหล่านั้นซึ่งบ่อยครั้งคุณไม่ต้องการ)
  • โปรดจำไว้ว่าฮาร์ดแวร์ในปัจจุบันมีราคาถูกอย่างน่าประหลาดใจดังนั้นอย่าลืมใช้ความพยายามในการปรับแต่งโค้ดขนาดใหญ่ให้เหมาะสมเมื่อเทียบกับ
  • ลองเพิ่มแท็ก "MySQL" และ "scaling" ในคำถามนี้

9

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

ฉันขอแนะนำให้เรียกใช้Xdebugเพื่อค้นหาคอขวดในโปรแกรมของคุณ มันทำให้การเพิ่มประสิทธิภาพเป็นเรื่องง่ายสำหรับฉัน


9

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

ลองทำแบบสอบถามฐานข้อมูลของคุณให้เข้าใจว่าอะไรช้าและเกิดอะไรขึ้นมากมายและคิดกลยุทธ์การเพิ่มประสิทธิภาพจากนั้น

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

การแยกฐานข้อมูลระหว่างเซิร์ฟเวอร์และใช้เทคนิคการปรับสมดุลโหลด (เช่นสร้างตัวเลขสุ่มระหว่างฐานข้อมูล 1 และ # ซ้ำซ้อนกับข้อมูลที่จำเป็น - และใช้หมายเลขนั้นเพื่อกำหนดว่าเซิร์ฟเวอร์ฐานข้อมูลใดที่จะเชื่อมต่อด้วย) สามารถเป็นวิธีที่ยอดเยี่ยม อย่างมีประสิทธิภาพ

สิ่งเหล่านี้ได้ผลค่อนข้างดีในอดีตสำหรับไซต์โหลดค่อนข้างสูง หวังว่านี่จะช่วยให้คุณเริ่มต้น :-)


1
RequiredFullQuote: "เราควรลืมประสิทธิภาพเล็กน้อยพูดประมาณ 97% ของเวลา: การปรับให้เหมาะสมก่อนกำหนดเป็นรากของความชั่วร้ายทั้งหมด"
Alister Bulman

RequiredReallyFullQuote: "โปรแกรมเมอร์เสียเวลาจำนวนมากไปกับการคิดหรือกังวลเกี่ยวกับความเร็วของส่วนที่ไม่สำคัญของโปรแกรมและความพยายามเหล่านี้อย่างมีประสิทธิภาพมีผลกระทบเชิงลบอย่างมากเมื่อพิจารณาการดีบักและบำรุงรักษาเราควรลืมประสิทธิภาพเล็กน้อย พูดถึง 97% ของเวลา: การปรับให้เหมาะสมก่อนวัยอันควรเป็นรากฐานของความชั่วร้ายทั้งหมด แต่เราไม่ควรปล่อยให้โอกาสของเราผ่านไปในช่วงวิกฤตที่ 3% "
cHao

6

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

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

แคช opcode ทุกประเภทสำหรับ PHP (เช่น APC หรือหนึ่งในหลาย ๆ ) จะช่วยได้มากเช่นกัน


6

ฉันใช้งานเว็บไซต์ที่มี 7-8 ล้านเพจวิวต่อเดือน ไม่มากนัก แต่พอที่เซิร์ฟเวอร์ของเรารู้สึกถึงภาระ โซลูชันที่เราเลือกนั้นง่ายมาก: Memcache ที่ระดับฐานข้อมูล วิธีนี้ใช้ได้ดีหากการโหลดฐานข้อมูลเป็นปัญหาหลักของคุณ

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

ดังนั้นเราจึงเปลี่ยนวิธีการของเรา เราสร้าง wrapper ของฐานข้อมูล (ด้วยวิธีการเดียวกันกับฐานข้อมูลเก่าของเราดังนั้นมันจึงง่ายต่อการสลับ) แล้วเราก็ทำการ subclassed เพื่อให้วิธีการเข้าถึงฐานข้อมูล memcached

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


6

สำหรับสิ่งที่คุ้มค่าการแคชคือ DIRT SIMPLE ใน PHP แม้ไม่มีแพ็คเกจเสริม / ตัวช่วยอย่าง memcached

สิ่งที่คุณต้องทำคือสร้างบัฟเฟอร์ผลลัพธ์โดยใช้ ob_start()ทั้งหมดที่คุณต้องทำคือการสร้างผลผลิตที่มีบัฟเฟอร์ใช้

สร้างฟังก์ชั่นแคชทั่วโลก โทรob_startผ่านฟังก์ชั่นการโทรกลับ ในฟังก์ชันให้ค้นหาหน้าเวอร์ชันที่แคชไว้ หากมีอยู่ให้บริการและสิ้นสุด

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

เพิ่มในคอลเลกชันหมดอายุ / ขยะบางส่วน

และหลายคนไม่ทราบว่าคุณสามารถวางสายob_start()/ ob_end()โทรได้ ดังนั้นหากคุณใช้บัฟเฟอร์เอาต์พุตเพื่อพูดแยกวิเคราะห์โฆษณาหรือเน้นไวยากรณ์หรืออะไรก็ตามคุณสามารถวางซ้อนการob_start/ob_endโทรอื่นได้


+1 เพราะดูเหมือนเป็นแนวคิดที่น่าสนใจ ผมไม่ทราบว่าทำงานได้ดีประสิทธิภาพฉลาด
Sylverdrag

+1 เพราะนี่เป็นแนวคิดที่น่าสนใจ การโทรกลับเหล่านั้นอาจเรียกคลาสแคชของฉันให้ฉันได้!
Xeoncross

5

ขอบคุณสำหรับคำแนะนำเกี่ยวกับส่วนขยายการแคชของ PHP - คุณช่วยอธิบายเหตุผลในการใช้ส่วนขยายได้หรือไม่ ฉันได้ยินสิ่งที่ยอดเยี่ยมเกี่ยวกับ memcached ผ่าน IRC แต่ไม่เคยได้ยิน APC - คุณมีความคิดเห็นอย่างไรกับพวกเขา? ฉันถือว่าการใช้ระบบแคชหลายแบบนั้นค่อนข้างมีประสิทธิภาพ

จริงๆแล้วหลายคนใช้ APC และ memcached เข้าด้วยกัน ...


4

ดูเหมือนว่าผมผิด MySQLi ยังคงพัฒนาอยู่ แต่ตามบทความ PDO_MySQL ได้รับการสนับสนุนจากทีมงาน MySQL แล้ว จากบทความ:

ส่วนต่อขยายที่ปรับปรุงจาก MySQL - mysqli - เป็นหลัก รองรับคุณสมบัติทั้งหมดของเซิร์ฟเวอร์ MySQL รวมถึง Charsets, Statement จัดทำและขั้นตอนการจัดเก็บ ไดรเวอร์มี API ไฮบริด: คุณสามารถใช้รูปแบบการเขียนโปรแกรมเชิงโพรซีเดอร์หรือเชิงวัตถุตามความต้องการของคุณ mysqli มาพร้อมกับ PHP 5 ขึ้นไป โปรดทราบว่าจุดสิ้นสุดของชีวิตสำหรับ PHP 4 คือ 2008-08-08

PHP Data Objects (PDO) เป็นเลเยอร์นามธรรมที่เป็นนามธรรม PDO ช่วยให้คุณใช้การเรียก API เดียวกันสำหรับฐานข้อมูลต่างๆ PDO ไม่เสนอระดับของนามธรรม SQL PDO_MYSQL เป็นไดรเวอร์ MySQL สำหรับ PDO PDO_MYSQL มาพร้อมกับ PHP 5 ในฐานะของนักพัฒนา MySQL 5.3 MySQL มีส่วนร่วมอย่างแข็งขัน ประโยชน์ PDO ของ API แบบครบวงจรมาในราคาที่คุณสมบัติเฉพาะของ MySQL เช่นคำสั่งหลายข้อความไม่ได้รับการสนับสนุนอย่างเต็มที่ผ่าน unified API

โปรดหยุดใช้ไดรเวอร์ MySQL ตัวแรกสำหรับ PHP ที่เคยเผยแพร่: ext / mysql นับตั้งแต่มีการเปิดตัว MySQL Improved Extension - mysqli - ในปี 2004 ด้วย PHP 5 ไม่มีเหตุผลที่จะยังคงใช้ไดรเวอร์ที่เก่าแก่ที่สุด ext / mysql ไม่รองรับ Charsets, Statement ที่เตรียมไว้, และ Stored Procedure มันถูก จำกัด ไว้ที่ชุดคุณสมบัติของ MySQL 4.0 โปรดทราบว่าการสนับสนุนเสริมสำหรับ MySQL 4.0 สิ้นสุดที่ 2008-12-31 อย่า จำกัด ตัวเองไว้ที่ฟีเจอร์ชุดของซอฟต์แวร์เก่า! อัปเกรดเป็น mysqli ดู Converting_to_MySQLi mysql อยู่ในโหมดบำรุงรักษาเท่านั้นจากมุมมองของเรา

สำหรับฉันดูเหมือนว่าบทความจะเอนเอียงไปทาง MySQLi ฉันคิดว่าฉันมีอคติต่อ PDO ฉันชอบ PDO มากกว่า MySQLi มันตรงไปข้างหน้ากับฉัน API นั้นใกล้เคียงกับภาษาอื่น ๆ ที่ฉันได้ตั้งโปรแกรมไว้ส่วนติดต่อฐานข้อมูล OO ดูเหมือนจะทำงานได้ดีขึ้น

ฉันยังไม่พบคุณสมบัติ MySQL เฉพาะที่ไม่สามารถใช้งานผ่าน PDO ฉันจะแปลกใจถ้าฉันเคยทำ


3

PDO นั้นช้ามากและ API นั้นค่อนข้างซับซ้อน ไม่มีใครในใจที่มีสติของพวกเขาควรใช้มันหากการพกพาไม่ใช่เรื่องที่น่ากังวล และลองเผชิญหน้ากับมันใน 99% ของ webapps ทั้งหมดมันไม่ได้เป็น คุณแค่ติดกับ MySQL หรือ PostrgreSQL หรืออะไรก็ตามที่คุณทำงานด้วย

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


2

PDO แน่ใจว่าเป็นสิ่งที่ดี แต่มีได้ รับ บางส่วนโต้เถียงเกี่ยวกับประสิทธิภาพของมันเมื่อเทียบกับ MySQL และ mysqli แม้ว่ามันจะดูเหมือนว่าตอนนี้คง

คุณควรใช้ pdo ถ้าคุณนึกถึงการพกพา แต่ถ้าไม่ใช่ mysqli ควรเป็นวิธี มันมีอินเตอร์เฟส OO ข้อความสั่งที่เตรียมไว้และสิ่งที่ pdo ส่วนใหญ่เสนอ (ยกเว้นความสามารถในการพกพา)

นอกจากนี้หากจำเป็นต้องใช้งานจริงให้เตรียมไดรเวอร์(เนทีฟ mysql) MysqLndใน PHP 5.3 ซึ่งจะรวมเข้ากับ php ได้แน่นขึ้นพร้อมประสิทธิภาพที่ดีขึ้นและการใช้หน่วยความจำที่ดีขึ้น (และสถิติสำหรับการปรับประสิทธิภาพ)

Memcache นั้นดีถ้าคุณมีเซิร์ฟเวอร์ที่ทำคลัสเตอร์ (และโหลดเหมือน YouTube) แต่ฉันลองใช้APCก่อนเช่นกัน


2

ได้รับคำตอบที่ดีมากมายแล้ว แต่ฉันอยากจะชี้ให้คุณไปที่แคช opcode สำรองที่เรียกว่าXCache XCacheมันถูกสร้างขึ้นโดยผู้มีส่วนร่วมที่มีน้ำหนักเบา

นอกจากนี้หากคุณอาจต้องการโหลดบาลานซ์เซิร์ฟเวอร์ฐานข้อมูลของคุณในอนาคตMySQL Proxyสามารถช่วยให้คุณประสบความสำเร็จได้เป็นอย่างดี

เครื่องมือทั้งสองนี้ควรเชื่อมต่อกับแอปพลิเคชันที่มีอยู่ได้อย่างง่ายดายดังนั้นการเพิ่มประสิทธิภาพนี้สามารถทำได้เมื่อคุณต้องการโดยไม่ต้องยุ่งยากมากเกินไป


2

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

ประสิทธิภาพไม่เกี่ยวข้องหากไซต์ไม่พร้อมใช้งาน และสำหรับความพร้อมใช้งานคุณจำเป็นต้องปรับสเกลแนวนอน ขั้นต่ำที่คุณสามารถทำได้ด้วย 2 เซิร์ฟเวอร์คือ apache, php และ mysql ตั้งค่าหนึ่ง DBMS เป็นทาสให้กับอีก ทำการเขียนทั้งหมดบนมาสเตอร์และอ่านทั้งหมดบนฐานข้อมูลโลคัล (ไม่ว่าจะเป็นอะไร) - ยกเว้นว่ามีเหตุผลบางอย่างที่คุณต้องอ่านข้อมูลที่คุณเพิ่งอ่าน (ใช้มาสเตอร์) ตรวจสอบให้แน่ใจว่าคุณมีเครื่องจักรในสถานที่เพื่อส่งเสริมการเป็นทาสโดยอัตโนมัติ ใช้ round-robin DNS สำหรับที่อยู่เว็บเซิร์ฟเวอร์เพื่อให้ความสัมพันธ์กับโหนดสลาฟมากขึ้น

การแบ่งพาร์ติชันข้อมูลของคุณในโหนดฐานข้อมูลที่แตกต่างกันในขั้นตอนนี้เป็นความคิดที่แย่มาก - อย่างไรก็ตามคุณอาจต้องการแยกมันออกจากฐานข้อมูลต่าง ๆ บนเซิร์ฟเวอร์เดียวกัน (ซึ่งจะช่วยแบ่งพาร์ติชันระหว่างโหนด

ตรวจสอบให้แน่ใจว่าคุณได้รับเครื่องมือตรวจสอบและวิเคราะห์ข้อมูลเพื่อวัดประสิทธิภาพเว็บไซต์ของคุณและระบุปัญหาคอขวด ปัญหาประสิทธิภาพส่วนใหญ่สามารถแก้ไขได้โดยการเขียน SQL ที่ดีขึ้น / แก้ไขสกีมาฐานข้อมูล

การเก็บแม่แบบแคชของคุณบนฐานข้อมูลเป็นแนวคิดที่โง่เง่าฐานข้อมูลควรเป็นแหล่งเก็บข้อมูลส่วนกลางสำหรับข้อมูลที่มีโครงสร้าง เก็บแม่แบบแคชของคุณไว้ที่ระบบไฟล์ในเครื่องของเว็บเซิร์ฟเวอร์ของคุณ - จะสามารถใช้งานได้เร็วขึ้นและจะไม่ทำให้การเข้าถึงฐานข้อมูลช้าลง

ใช้แคชรหัส op-code

ใช้เวลามากมายในการศึกษาเว็บไซต์ของคุณและบันทึกของเว็บไซต์เพื่อทำความเข้าใจว่าเหตุใดเว็บไซต์จึงทำงานช้า

ผลักแคชให้มากที่สุดเท่าที่จะทำได้ไปยังลูกค้า

ใช้ mod_gzip เพื่อบีบอัดทุกสิ่งที่คุณทำได้

ค.


2

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

โดยทั่วไปแล้วSimple นั้นรวดเร็วที่เรียบง่ายเป็นไปอย่างรวดเร็วเทมเพลตทำให้คุณช้าลง ฐานข้อมูลทำให้คุณช้าลง ห้องสมุดที่ซับซ้อนทำให้คุณช้าลง เลย์เอาต์เทมเพลตซึ่งกันและกันจะดึงข้อมูลจากฐานข้อมูลและแยกวิเคราะห์ในไลบรารีที่ซับซ้อน -> เวลาที่ล่าช้าจะทวีคูณซึ่งกันและกัน

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

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


1

@ Gary

อย่าใช้ MySQLi - PDO เป็นเลเยอร์การเข้าถึงฐานข้อมูล 'ทันสมัย' OO คุณลักษณะที่สำคัญที่สุดที่จะใช้คือตัวยึดตำแหน่งในแบบสอบถามของคุณ มันฉลาดพอที่จะใช้การเตรียมฝั่งเซิร์ฟเวอร์และการเพิ่มประสิทธิภาพอื่น ๆ สำหรับคุณเช่นกัน

ตอนนี้ฉันดูดีมาก PDO และดูเหมือนว่าคุณถูกต้อง - แต่ฉันรู้ว่า MySQL กำลังพัฒนาส่วนขยาย MySQLd สำหรับ PHP - ฉันคิดว่าจะประสบความสำเร็จทั้ง MySQL หรือ MySQLi - คุณคิดอย่างไร


@ Ryan , Eric , tj9991

ขอบคุณสำหรับคำแนะนำเกี่ยวกับส่วนขยายการแคชของ PHP - คุณช่วยอธิบายเหตุผลในการใช้ส่วนขยายได้หรือไม่ ฉันได้ยินสิ่งที่ยอดเยี่ยมเกี่ยวกับ memcached ผ่าน IRC แต่ไม่เคยได้ยิน APC - คุณมีความคิดเห็นอย่างไรกับพวกเขา? ฉันถือว่าการใช้ระบบแคชหลายแบบนั้นค่อนข้างมีประสิทธิภาพ

ฉันจะเรียงลำดับผู้ทดสอบโปรไฟล์ออกไปอย่างแน่นอน - ขอบคุณมากสำหรับคำแนะนำของคุณ


1

ฉันไม่เห็นตัวเองเปลี่ยนจาก MySQL เมื่อเร็ว ๆ นี้ - ดังนั้นฉันเดาว่าฉันไม่ต้องการความสามารถด้านนามธรรมของ PDO ขอบคุณสำหรับบทความเหล่านั้น DavidM พวกเขาช่วยฉันมาก


1

มองหาmod_cacheซึ่งเป็นแคชเอาต์พุตสำหรับเว็บเซิร์ฟเวอร์ Apache, simillar to output caching ใน ASP.NET

ใช่ฉันเห็นว่ามันยังอยู่ในช่วงทดลอง แต่จะเป็นวันสุดท้าย


1

ฉันไม่อยากจะเชื่อเลยว่าไม่มีใครพูดถึงเรื่องนี้: Modularisation และ Abstraction หากคุณคิดว่าเว็บไซต์ของคุณจะต้องเติบโตเป็นจำนวนมากคุณต้องออกแบบมันให้ได้! นั่นหมายถึงสิ่งที่โง่เช่นอย่าคิดว่าฐานข้อมูลอยู่บน localhost นอกจากนี้ยังหมายถึงสิ่งต่าง ๆ ที่น่ารำคาญในตอนแรกเช่นการเขียนเลเยอร์สิ่งที่เป็นนามธรรม (เช่น PDO แต่เบากว่ามากเพราะมันทำในสิ่งที่คุณต้องการเท่านั้น)

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

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


1

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


1

จุดที่ทำเกี่ยวกับแคชเป็นจุดบน; มันเป็นส่วนที่ซับซ้อนน้อยที่สุดและสำคัญที่สุดในการสร้างแอปพลิเคชั่นที่มีประสิทธิภาพ ฉันต้องการเพิ่มในขณะที่ memcached ดีมาก APC เร็วขึ้นประมาณห้าเท่าหากแอปพลิเคชันของคุณใช้งานเซิร์ฟเวอร์เดียว

"การแคชเปรียบเทียบผลการดำเนินงาน" โพสต์ในบล็อกของประสิทธิภาพการทำงานของ MySQL มีมาตรฐานที่น่าสนใจเกี่ยวกับเรื่องบาง - http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/

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