คุณกำลังเข้าสู่โลกแห่งการเพิ่มประสิทธิภาพที่กว้างและกว้างขวางที่นี่และแน่นอนว่าไม่ใช่ขนาดที่เหมาะกับทุกแนวทาง
กำหนดประสิทธิภาพ
คุณหมายถึงความเร็วในการโหลดหน้าเว็บสำหรับผู้ใช้รายเดียวหรือความจุโดยรวม / การทำงานพร้อมกันทั้งหมดหรือไม่ ทั้งสองมีความแตกต่างอย่างชัดเจน - และไม่เกี่ยวข้องกันอย่างเคร่งครัด เป็นไปได้ทั้งหมดที่จะมีร้านค้าที่รวดเร็วและมีความจุ จำกัด หรือร้านค้าช้าที่มีความจุมาก
ดังนั้นเมื่อกล่าวถึงประสิทธิภาพการทำงานทั้งสองประเภท:
- ผู้ใช้คนเดียวรับรู้เวลาในการโหลดหน้าเว็บ
- กำลังการผลิตรวม / การทำงานพร้อมกัน
คุณต้องแก้ไขปัญหาด้วยตนเองโดยเฉพาะเนื่องจากแต่ละคนมีปัญหาคอขวดของตนเอง
ให้สมมุติว่าคุณอยู่กับโฮสต์ที่มีคุณสมบัติที่กำหนดค่าด้านอื่น ๆ ของเซิร์ฟเวอร์ของคุณอย่างเหมาะสมที่สุดสำหรับร้านค้าของคุณ
ผู้ใช้คนเดียวรับรู้เวลาในการโหลดหน้าเว็บ
MySQL เป็นคอขวด
ที่ไม่ใช่โดยตรง ทุกอย่างเกี่ยวกับเวลาแฝงในกรณีส่วนใหญ่เมื่อทดสอบเวลาโหลดหน้า - เฉพาะแคชจะถูกตี ดังนั้นกุญแจที่นี่คือการลดความหน่วงแฝง
- ปรับขนาดแคชของแคช MySQL อย่างเหมาะสม (ไม่มีคำตอบที่ถูกต้องเราปรับการตั้งค่าแตกต่างอย่างสิ้นเชิงรายเดือนต่อร้าน)
- ลดเวลาในการตอบสนองของเครือข่าย สำหรับ 64 ไบต์เฟรม 51.2 สำหรับ 10Mbps, 5.12µs สำหรับ 100Mbps และ 4.096µs สำหรับ 1Gbps สิ่งนี้ให้การปรับปรุง 20% เพียงแค่เปลี่ยนจาก 100Mbps เป็น 1Gbps s1
- เพิ่มความจุเครือข่าย คุณจะประหลาดใจที่หลายเมกะไบต์ต่อความเป็นอยู่ที่สองการแลกเปลี่ยนระหว่างเว็บและเซิร์ฟเวอร์ฐานข้อมูลมักจะอยู่ในส่วนที่เกิน 10MB / s - ดังนั้นขั้นต่ำ 100Mb A / S จะต้องs1 หรือเพียงแค่ย้ายเซิร์ฟเวอร์ DB ในเครื่อง
- ใช้ SOLR เครื่องมือภายนอกบางครั้งก็เป็นความเหมาะสมดีกว่า, SOLR แน่นอนเร็วขึ้นสำหรับแคตตาล็อกขนาดใหญ่ (และฉันต้องการความเครียดแคตตาล็อกขนาดใหญ่ ) แม้แต่ SOLR ที่ไม่ได้ปรับแต่งก็ยังสามารถสร้างการนำทางแบบเลเยอร์และผลการค้นหาได้เร็วกว่า MySQL
แต่การเปลี่ยนแปลงเหล่านี้จะส่งผลกระทบเพียงเล็กน้อยต่อเวลาในการโหลดหน้าเว็บซึ่งเป็นจุดที่เกิดปัญหาคอขวด
- ปรับแต่งแอปพลิเคชัน Magento มีข้อบกพร่องที่ค่อนข้างใหญ่ด้วยวิธีการสร้างคอลเลกชันและแคชพวกมัน เราได้พบกับปัญหารหัสหลักขนาดใหญ่ที่สามารถทำลายประสิทธิภาพการทำงาน ในบางกรณีเพียงแค่ลบการแสดงจำนวนผลิตภัณฑ์บนผลลัพธ์การนำทางแบบเลเยอร์โกน 2 วินาทีของการโหลดคอลเล็กชันขนาดใหญ่
- ตรวจสอบ MySQL บันทึกช้า ตรวจสอบแบบสอบถามที่ช้าและเพิ่มดัชนีตามที่จำเป็น ความแตกต่างระหว่างการทำงานแบบสอบถามที่ซับซ้อนที่มีหลายร่วมที่มีและไม่มีดัชนีที่เหมาะสมสามารถนับวินาที
แอปพลิเคชันเป็นคอขวด ไม่ใช่ซอฟต์แวร์ ดังนั้นเพียงแค่การปรับปรุงคอร์โค้ดหรือการทำให้เทมเพลตของคุณมีน้ำหนักน้อยลงจะส่งผลต่อประสิทธิภาพการทำงานมากกว่าการเปลี่ยนแปลงการตั้งค่า MySQL ใด ๆ
สิ่งที่เราจะไม่รบกวน
- การเปลี่ยนเอนจิ้นการจัดเก็บ MariaDB และ Percona แชร์เอ็นจิ้น InnoDB เดียวกัน - Percona XtraDB พวกเขาสามารถถือว่าเป็นหนึ่งเดียวกัน ในแง่ของเวลาดำเนินการแบบสอบถามเดียว - ประสิทธิภาพจะสะท้อนการสร้างวนิลา MySQL สิ่งนี้เกิดขึ้นภายใต้การโหลด / การทำงานพร้อมกัน
- ใช้ทาส MySQL สิ่งนี้จะไม่ปรับปรุงประสิทธิภาพเว้นแต่ทาสจะอยู่ใกล้กว่าทางกายภาพ (จากมุมมองเครือข่าย) หรือว่าทาสมีฮาร์ดแวร์ที่ดีกว่าต้นแบบ สิ่งนี้เกิดขึ้นภายใต้การโหลด / การทำงานพร้อมกัน
- ใช้เซิร์ฟเวอร์ฐานข้อมูลภายนอก นี่คือคำแนะนำที่เลวร้ายที่สุดที่เราเห็นเจ้าของ / เอเจนซี่หลายคนพูดซ้ำ ๆ จนกว่าคุณจะประสบปัญหาเรื่องฮาร์ดแวร์ / ทรัพยากรหรือคุณมีเว็บเซิร์ฟเวอร์หลายตัว (อ่าน: ความพร้อมใช้งานสูง), MySQL บนเครื่องท้องถิ่นสำหรับร้าน Magento เป็นแนวคิดที่ดี มันตัดค่าใช้จ่ายเครือข่ายและความล่าช้าทั้งหมด แม้แต่เครือข่าย 100Gb / s (ใช่หนึ่งร้อยกิกะบิตต่อวินาที) จะไม่เปรียบเทียบกับซ็อกเก็ตยูนิกซ์ท้องถิ่นสำหรับปริมาณดิบปริมาณงานและความหน่วง
s1สำหรับเซิร์ฟเวอร์ฐานข้อมูลแยกต่างหากเท่านั้น ไม่ได้ใช้กับเซิร์ฟเวอร์ฐานข้อมูลท้องถิ่น
กำลังการผลิตรวม / การทำงานพร้อมกัน
MySQL เป็นคอขวด
หรือเปล่า แต่เมื่อคุณตอกย้ำประสิทธิภาพการทำงานของ PHP และความสามารถจนถึงจุดที่ MySQL กำลังทำให้สิ่งต่าง ๆ ช้าลง หากคุณมี Varnish และ FPC ได้รับการกำหนดค่าอย่างเหมาะสม (อย่าให้เราเริ่มต้นจากความพยายามที่ล้มเหลวหลายครั้งที่เราเคยเห็น) - MySQL จะกลายเป็นคอขวด
ดังนั้นนอกจากการแก้ไขข้างต้น
- เปลี่ยนเอ็นจิ้น MySQL XtraDB สามารถ excel ภายใต้การโหลดและแสดงผลประโยชน์ของแท้เหนือการกระจาย MySQL หุ้น
- พักอาศัยอยู่กับ MySQL 5.5 ทำงานได้ดีกว่า 5.0 ภายใต้การโหลด
- เปลี่ยนไดรเวอร์ PHP MySQL PHP 5.3 และใหม่กว่ามีไดร์เวอร์ MySQL ดั้งเดิม แต่ในบางกรณีเราพบ PHP 5.2 พร้อมไดร์เวอร์แยกต่างหากเพื่อให้ทำงานได้ดีกว่า MySQLND สำหรับ Magento ทดสอบด้วยตัวคุณเอง
- เปลี่ยนเครื่องมือค้นหา การย้ายการค้นหาไปยัง SOLR / Sphinx (หรือแม้แต่บริการภายนอกของบุคคลที่สาม) สามารถลดภาระของการโหลดที่ไม่ใช่ธุรกรรม (เช่นผู้ที่ไม่ได้สั่งซื้อ)
- เปลี่ยนเครื่องมือการนำทางแบบเลเยอร์ อีกครั้ง SOLR เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการนำทางแบบเลเยอร์และเนื่องจากลักษณะที่ไม่ล็อคจะเร็วกว่า MySQL
- เพิ่ม MySQL slave นี้จะช่วยเหลือในการเรียกดู (ไม่ใช่การทำธุรกรรม) โหลด แต่จะไม่ช่วยให้คุณสามารถดำเนินการสั่งซื้อมากขึ้นต่อชั่วโมง - มันเป็นพึ่งพาปริญญาโทในการกระบวนการและการทำซ้ำข้อมูลนี้
สิ่งที่เราจะไม่รบกวน
- ปริญญาโท / ปริญญาโท เนื่องจากจุดเปลี่ยนที่สูงมากของความอิ่มตัวของฮาร์ดแวร์ของการตั้งค่า Master / Slave (เกินกว่า 1,000 คำสั่งต่อชั่วโมง) - เราไม่เคยพบความต้องการในการใช้งาน Master / Master ในการผลิต เราได้ทำการทดสอบอย่างกว้างขวาง แต่ไม่เคยพบว่ามันจะได้ประโยชน์จากมุมมองด้านประสิทธิภาพและด้วยความเสี่ยงและปัญหาที่เกิดขึ้นจริงของ Master / Master มันไม่คุ้มค่าเลย
อ่าน vs เขียนขยายขีดความสามารถ
ย่อหน้าสุดท้ายนำไปสู่พื้นที่สำคัญของการอ่านและการขยายขีดความสามารถ การอ่านสเกลสามารถทำได้อย่างไม่มีที่สิ้นสุดโดยไม่เกิดความยุ่งยากมากเกินไปหากเพิ่มทาสมากขึ้น
อัตราส่วนของการอ่านเพื่อเขียนของวีโอไอพีนั้นอยู่ที่ประมาณ 0.1% - การพิจารณาว่าการเขียนไม่น่ากังวลมากนัก นั่นเป็นเหตุผลที่ฉันไม่ใส่ใจที่จะกล่าวถึงMySQL Clusterและคุณสมบัติที่ชาญฉลาดเช่นการแบ่งส่วนอัตโนมัติ (แยกตารางออกเป็นเครื่องแยกต่างหาก)
ฮาร์ดแวร์ฮาร์ดแวร์ฮาร์ดแวร์
ฮาร์ดแวร์เป็นคำตอบที่รวดเร็วที่สุดเมื่อพูดถึงการปรับปรุงดังนั้นฉันจึงไม่ได้กล่าวถึงข้างต้นในทั้งสองสถานการณ์
แต่การเปลี่ยนแปลงซอฟต์แวร์ทั้งหมดในโลกจะไม่สร้างความแตกต่างถ้าฮาร์ดแวร์พื้นฐานของคุณไม่เพียงพอ นั่นอาจหมายถึง ...
- สวิตช์คุณภาพต่ำพร้อมบัฟเฟอร์ จำกัด
- ลิงก์เครือข่ายที่อิ่มตัวมากเกินไป
- เซิร์ฟเวอร์ที่อยู่ห่างไกลทางภูมิศาสตร์
- เครือข่ายไม่ดี QoS / CoS
- จำนวน RAM ทั้งหมดที่ จำกัด
- RAM แบนด์วิดธ์หน่วยความจำต่ำ
- ระบบย่อย HDD HDD ต่ำของ IOPs
- ซอฟต์แวร์ RAID คอนโทรลเลอร์
- CPU ความเร็วสัญญาณนาฬิกาต่ำ
- ชิปเซ็ตแบนด์วิดธ์ต่ำ
- การจำลองเสมือนสำหรับฮาร์ดแวร์ (เกือบทุกประเภทนอกเหนือจากการจำลองเสมือนระดับเคอร์เนล)
ทุกวันนี้มีเพดานที่สูงมากสำหรับความสามารถในการปรับขนาดของฮาร์ดแวร์ ให้เพิกเฉยต่อตำนานของการปรับขนาดที่ไม่มีที่สิ้นสุด "ในคลาวด์" เนื่องจากฮาร์ดแวร์ของคลาวด์มีแนวโน้มที่จะปานกลาง ตัวอย่างเช่นรุ่นเรือธงของ Amazon มี 12 Cores @ 3.3GHz เท่านั้น แต่นอกเหนือจากนี้มีเซิร์ฟเวอร์ที่ทรงพลังมากบางตัว - เซิร์ฟเวอร์อันดับต้น ๆ ของเรามี 160 คอร์และ 2TB (ใช่เทราไบต์) ของ RAM เรายังไม่เห็นใครเกินขีดความสามารถของมัน
ดังนั้นคุณจึงมีขอบเขตขนาดใหญ่สำหรับการปรับขนาดแนวตั้งก่อนที่คุณจะต้องพิจารณาการปรับขนาดแนวนอน
เป้าหมายที่เคลื่อนไหว
มูลค่าการกล่าวขวัญว่าในการแสวงหาประสิทธิภาพคอขวดจะเคลื่อนไหวตลอดเวลา
สำหรับร้านค้า Magento
เปิดแคช PHP เป็นคอขวด
เพิ่มแคชแบ็กเอนด์ PHP เป็นคอขวด
เพิ่มแคชแบบเต็มหน้าระดับแอปพลิเคชัน PHP เป็นคอขวด
เพิ่มแคชหน้าเซิร์ฟเวอร์ (เช่นวานิช) MySQL เป็นคอขวด
เพิ่มการค้นหาทางเลือก / เครื่องมือนำทางชั้น (เช่น SOLR / สฟิงซ์) PHP เป็นคอขวด
เพิ่มแอพพลิเคชันเซิร์ฟเวอร์ให้มากขึ้น MySQL เป็นคอขวด
เพิ่มทาส MySQL แคช Front-end เป็นคอขวด
เพิ่มเซิร์ฟเวอร์แคช front-end เพิ่มเติม PHP เป็นคอขวด
เพิ่มแอพพลิเคชันเซิร์ฟเวอร์ให้มากขึ้น SOLR / Sphinx เป็นคอขวด
etcetera
มันค่อนข้างจะกลายเป็นกรณีของการล้างซ้ำ แต่สิ่งที่ชัดเจนในการเข้าใจคือว่า MySQL ไม่ใช่พอร์ตแรกของการเพิ่มประสิทธิภาพและจริงๆแล้วจะเกิดขึ้นเมื่อ MySQL ใช้ CPU มากขึ้นตามสัดส่วนของ PHP และสิ่งนี้จะเกิดขึ้นเมื่อทั้ง FPC และ Varnish ใช้งานอยู่ และเซิร์ฟเวอร์กำลังประมวลผลคำสั่งอย่างหมดจดและไม่มีอะไรมาก (เพราะทุกอย่างอื่นอยู่ในแคช)
อย่าทำการเปลี่ยนแปลงแบบสุ่มสี่สุ่มห้า
เพียงเพิ่มทาส MySQL เพราะคุณอ่านเราพูดไปแล้วว่ามันจะช่วยให้คุณสามารถเสียค่าใช้จ่ายประสิทธิภาพและความน่าเชื่อถือในระดับสูง เครือข่ายที่แออัด, เซิร์ฟเวอร์สเป็คต่ำหรือการตั้งค่าที่ไม่เหมาะสมอาจทำให้เกิดปัญหาการจำลองแบบที่สามารถทำให้ร้านค้าของคุณช้ากว่าที่จะเริ่มต้นด้วย - หรือทำให้เกิดปัญหาการประสานระหว่าง Master และ Slave
เพื่อนำสิ่งต่าง ๆ ไปสู่มุมมอง - ตัวอย่างจากโลกแห่งความจริง
ตัวอย่างที่ 1 - 300 คำสั่งต่อชั่วโมง
เราได้ใช้ฮาร์ดแวร์ต่อไปนี้จะให้บริการ300 คำสั่งต่อชั่วโมง ; และที่จุดเปลี่ยนเท่านั้น - เรารู้สึกว่าจำเป็นต้องเพิ่มเซิร์ฟเวอร์ MySQL เฉพาะและทาส MySQL ท้องถิ่น
1 เซิร์ฟเวอร์
CPU: 2x Intel E5-4620
RAM: 64GB HDD: 4x80k IOP / s SSDs
RAID: ฮาร์ดแวร์ RAID 10
Magento รุ่น: Magento EE
OS: MageStack
ในช่วงเวลาทั้งหมดโหลดเฉลี่ยยังคงต่ำกว่า 3.00
ตัวอย่างที่ 2 - 180 คำสั่งต่อชั่วโมง
เพียงสองวันที่ผ่านมาลูกค้าใหม่ของเราสามารถเพิ่มจำนวนผู้เข้าชมได้อย่างง่ายดาย การประมวลผลคำสั่งซื้อ 180 ต่อชั่วโมงกับเซิร์ฟเวอร์เดียวและวีโอไอพีชุมชน Edition
1 เซิร์ฟเวอร์
CPU: 2x Intel E5-4620
RAM: 64GB HDD: 4x80k IOP / s SSDs
RAID: ฮาร์ดแวร์ RAID 10
Magento เวอร์ชั่น: Magento CE
OS: MageStack
เว็บไซต์: Wellgosh.com
ในช่วงเวลาทั้งหมดโหลดเฉลี่ยยังคงต่ำกว่า 6.00 การโหลดสูงขึ้นในสถานการณ์นี้และนั่นเป็นปัจจัยสองสามประการ
- ไม่มีการปรับแต่งร้านค้าเหมือนในตัวอย่างที่ 1
- การขาด FPC ระดับแอปพลิเคชัน
และด้วยความใหม่ล่าสุดของเรื่องนี้เรายังคงมีสถิติโดยละเอียดเพื่อแสดงความคิดเห็นผ่านกราฟ สิ่งเหล่านี้บอกเล่าเรื่องราวที่ยอดเยี่ยมของการกระจายโหลดระหว่างองค์ประกอบหลักของสถาปัตยกรรม Magento ที่แยกจากกัน (load balancer, เว็บเซิร์ฟเวอร์, เซิร์ฟเวอร์ db ฯลฯ - โดยใช้MageStack )
ดังนั้นจากด้านหน้าไปข้างหลัง ... วันที่คุณต้องการดูคือเวลา 12:00 น. ของวันที่ 22 กุมภาพันธ์
แพ็กเก็ตไฟร์วอลล์
สารเคลือบเงาจราจร
การจราจร Nginx
โหลด MySQL
โหลดซีพียู
และที่สำคัญที่สุดคือการกระจายของโหลด
ภาพนี้บอกทุกอย่างจริงๆ และนั่นก็คือ MySQL ไม่ได้เป็นภาระอย่างแน่นอน ดังนั้นคำแนะนำของเราให้มุ่งเน้นเรื่องประสิทธิภาพของคุณที่อื่นเว้นแต่คุณกำลังประมวลผลคำสั่งมากกว่าสองพันคำสั่งต่อชั่วโมง
และโดยสรุป
การเปลี่ยนแปลงประสิทธิภาพไม่ใช่ "หนึ่งขนาดเหมาะกับทุกคน" เป็นกรณีของการวิเคราะห์คอขวดปัจจุบันของคุณและทำการเปลี่ยนแปลง / ปรับเปลี่ยนเล็กน้อยเพื่อให้เหมาะกับร้านค้าและโครงสร้างพื้นฐานของคุณ
แต่ประสิทธิภาพที่นอกเหนือไปจากการใช้ Percona ยังมีประโยชน์อื่นอีกมากมาย
เราใช้ Percona XtraDB เกือบเฉพาะ เราใช้งานบิวด์คอมไพล์ของ MySQL ที่เราพัฒนาขึ้นมาเพื่อ Magento โดยเฉพาะและได้ปรึกษากับ Percona ในระหว่างกระบวนการ แต่มันไม่ใช่แค่การแสดงที่มีอิทธิพลต่อตัวเลือกนี้
- ชุดเครื่องมือ Percona
- PT-แบบสอบถามย่อย
- xtrabackup
- เป็นต้น
- ความถี่ในการปล่อย Percona
- การสนับสนุนให้คำปรึกษา Percona
- Warm cache เริ่มต้นใหม่ด้วยการเก็บรักษาพูลของ InnoDB
และอีกมากมาย ดังนั้นการใช้มันผ่าน MySQL จึงมีข้อได้เปรียบมากกว่าประสิทธิภาพ ในความเป็นจริง - MySQL นั้นเป็นสิ่งที่เรากังวลน้อยที่สุดในการแสวงหาประสิทธิภาพและความเสถียร
การแสดงที่มา: wellgosh.com , sonassi.com , iebmedia.com