ปัญหาประสิทธิภาพการทำงานกับเว็บไซต์ / ร้านค้าขนาด 1k to 10k


9

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

  1. การเพิ่มเว็บไซต์ / ร้านค้าใหม่ช้า
    ฉันแสดงความคิดเห็น $ this-> cleanModelCache () ใน _afterSave () ใน Mage_Core_Model_Abstract และสถานการณ์ดูดีขึ้น แต่เริ่มช้าลงด้วยจำนวนเว็บไซต์ / ร้านค้าที่เพิ่มขึ้น และฉันไม่รู้ว่าสิ่งนี้จะส่งผลกระทบต่อระบบทั้งหมดในอนาคต

  2. การเรียก API ช้าลง
    หนึ่งในกระบวนการหลักคือการสั่งซื้อ โมเดลที่กำหนดเองของฉันเกี่ยวข้องกับมันโดยการประมวลผลข้อมูลบางส่วนและใช้โมเดลการขาย / เสนอราคาและโมเดลการขาย / service_quote กระบวนการเริ่มต้นด้วย Oauth ทั้ง Oauth และการสั่งซื้อจะใช้เวลานานขึ้นเมื่อจำนวนเว็บไซต์ / ร้านค้าโตขึ้นและปริมาณการใช้หน่วยความจำดูใหญ่ขึ้น สิ่งนี้เกี่ยวข้องกับ Mage ในการโหลด config xml หรือไม่และข้อเท็จจริงที่ว่าข้อมูลการกำหนดค่ามีขนาดใหญ่ขึ้นด้วยจำนวนเว็บไซต์ที่เพิ่มขึ้นหรือไม่

  3. การเปิดตัว n98-magerun dev: คอนโซลใช้เวลานาน ไม่ทราบสาเหตุของมัน

  4. การบันทึกการกำหนดค่าจากแผงผู้ดูแลระบบใช้เวลานานกว่า ไม่รู้จะปรับปรุงมันอย่างไร

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

อินสแตนซ์ Magento ปัจจุบัน: Version = Magento EE 1.14.2.4;
กำหนดค่าแคช ปิดแคชอื่น ๆ
ใช้ Mysql 5.6 และ MongoDB (สำหรับ catalog_category_entity, catalog_product_entity, core_website);
จำนวนเว็บไซต์ = จำนวนร้านค้า = จำนวนการดู = 1024;
จำนวนผลิตภัณฑ์ = 4501;

ขอบคุณทุกคนล่วงหน้า!


2
ทำไมการสนับสนุนคุณภาพเยี่ยมไม่สามารถช่วยคุณได้ ???
MagenX

ฉันจะรับความช่วยเหลือจากพวกเขาได้อย่างไร ฉันยังใหม่ต่อชุมชน .. ขอบคุณ!
แจ็ค.

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

1
แต่คำตอบที่ชัดเจนสำหรับคำถามของคุณคือ - แยกร้านค้าวีโอไอพีที่มีฐานข้อมูลแยกต่างหากเช่นแบทช์ต่อร้านค้า 10-20 ...
MagenX

อ่า .. ฉันขอหัวหน้าบัญชีของฉันด้วยฮ่าฮ่า
แจ็ค.

คำตอบ:


3

หนึ่งในเหตุผลที่ทำให้ช้าคือเนื่องจากการกำหนดค่าสำหรับแต่ละร้านซ้ำจาก / config / เว็บไซต์และ / config / global และรหัสสำหรับการทำที่ไม่ได้มีประสิทธิภาพอย่างน้อย การเปลี่ยนแปลงการตั้งค่าใด ๆ อาจทำให้เกิด 10 นาทีหลายนาทีหากไม่ใช่ชั่วโมงของประสิทธิภาพที่ลดลงและปริมาณงาน การทำให้มีประสิทธิภาพมากขึ้นโดยทั่วไปจะหมายถึงว่า Ben Marks จะมาตามคุณ ... และไม่ใช่ในทางที่ดี

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

[เพิ่ม]

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

ไม่ว่าจะด้วยวิธีใดร้านค้า 10k Magento ก็สามารถทำได้โดยที่ไม่สามารถทำได้ แต่มันจะเป็นถนนที่ยากลำบากไม่ว่าเส้นทางไหนที่คุณเลือก


สวัสดีเควินขอบคุณสำหรับคำตอบของคุณ! ใช่ฉันเห็นรหัสที่อัปเดตทรี config ซึ่งเป็น loadToXml () ถ้าฉันไม่ผิด ความคิดของฉันคือ; และคุณบอกว่ามันไม่ควรแก้ไขหรือไม่ คุณหมายถึงอะไรโดย Ben Marks ที่ตามฉันมา? นอกจากนี้ดูเหมือนว่าคำขอ http แต่ละรายการที่มากับ Magento ในที่สุดจะโหลดทรี config ได้ถูกต้องหรือไม่ มีวิธีใดที่ฉันสามารถลดขนาดของมันได้ ฉันควรจะคิดเกี่ยวกับการรับอินสแตนซ์ 10k Magento ... ความคิดใด ๆ เกี่ยวกับทรัพยากรที่จำเป็นต้องใช้? ขอบคุณเควินมาก!
แจ็ค.

แต่มีการติดตั้ง 10k Magento หมายถึง 10k mysql อินสแตนซ์ใช่ไหม? ฉันไม่รู้ว่าจะทำอย่างไรหรือถ้าเป็นความคิดที่ดี ..
แจ็ค.

1
ไม่มันหมายถึงการมีฐานข้อมูล 10k mysql แต่ทั้งหมด 10k นั้นอาจอยู่ใน mysql เพียงตัวอย่างเดียว
คริสเตียน

1
"Ben Marks" มาหลังจากที่คุณอ้างอิงถึงcamo.githubusercontent.com/
เควินชโรเดอร์

1
การติดตั้ง 10k Magento หมายถึงฐานข้อมูล MySQL 10k อย่างไรก็ตามนั่นจะเป็นการกระจายออกไป มันจะง่ายกว่ามากในการปรับใช้สคริปต์การติดตั้งวีโอไอพีแบบบุคคลละ 10k กว่าจะเป็นการทำให้คอร์โค้ดที่มีอยู่ใช้งานได้กับร้านค้า 10k
Kevin Schroeder

1

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

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

หากคุณสามารถควบคุมเซิร์ฟเวอร์ฐานข้อมูลของคุณได้: เปลี่ยนชื่อตาราง core_config_data เป็น core_config_data_offline สร้างตาราง core_config_data ใหม่โดยใช้ MEMORY storage engine http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html คัดลอกข้อมูลทั้งหมดจาก core_config_data_offline ไปยัง core_config_data

ตั้งค่างาน cron เพื่อตรวจสอบว่ามี core_config_data อยู่หรือไม่หากคัดลอกข้อมูลทั้งหมดจากที่นั่นไปยัง core_config_data_offline หากไม่มีให้สร้างและคัดลอกทุกอย่างจาก core_config_data_offline ไปยัง core_config_data

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

คุณอาจต้องการทดสอบด้วยการเปลี่ยนไฟล์ Mage / Core / Model / Config.php และเปิดใช้งานแคชแต่ละเว็บไซต์ โดยค่าเริ่มต้นข้อมูลการกำหนดค่าเฉพาะของแต่ละร้านจะถูกแคชแยกกัน ข้อมูลการกำหนดค่าเว็บไซต์ทั้งหมดถูกแคชไว้ในวัตถุเดียว

โปรดทราบว่านี่เป็นเพียงการแทนที่การกำหนดค่า [การตั้งค่าผู้ดูแลระบบ] ดังนั้นหากคุณทำการเปลี่ยนแปลงการกำหนดค่าทั้งหมดที่ระดับร้านค้าของคุณตั้งค่าไว้แล้ว หากคุณใช้ "สืบทอดจากเว็บไซต์" และทำการเปลี่ยนแปลงการกำหนดค่าเฉพาะของร้านค้าส่วนใหญ่ที่ระดับไซต์ - แคชจะมีทุกเว็บไซต์ คุณสามารถแยกมันออกได้ดีกว่ามาก ป้องกัน $ _cacheSections = array ('admin' => 0, 'adminhtml' => 0, 'crontab' => 0, 'ติดตั้ง' => 0, 'stores' => 1, 'เว็บไซต์' => 0);

ถึง

protected $_cacheSections = array(
    'admin'     => 0,
    'adminhtml' => 0,
    'crontab'   => 0,
    'install'   => 0,
    'stores'    => 1,
    'websites'  => 1
); 

สวัสดี Gary ขอบคุณสำหรับคำตอบที่เป็นประโยชน์เช่นนี้! ฉันมีคำถาม: 1) จากการสังเกตของฉันแบบสอบถามฐานข้อมูลไม่เป็นปัญหาแม้แต่กับเว็บไซต์ / ร้านค้ามากกว่า 1k; ดังนั้นหากเป็นเช่นนั้นการใช้ที่เก็บข้อมูลหน่วยความจำจะยังคงช่วยได้หรือไม่ 2) ฉันไม่รู้ว่าถูกต้องหรือไม่ แต่ config cache ดูเหมือนจะเก็บข้อมูลระบบและโมดูลเท่านั้น มันมีบางอย่างเกี่ยวข้องกับการกำหนดค่าเว็บไซต์ / ร้านค้าหรือไม่ 3) มีวิธีใดที่วีโอไอพีจะจดจำรหัสร้านค้า / เว็บไซต์เฉพาะจากคำขอ http ดังนั้นจึงโหลดเฉพาะไฟล์ปรับแต่งที่เกี่ยวข้องเท่านั้น ขอบคุณมาก Gary!
แจ็ค.

2
คำแนะนำเหล่านี้ไม่ได้แก้ไขปัญหาที่ OP สังเกต การปิดการกำหนดค่าแคชท้ายที่สุดจะฆ่าระบบ มันจะทำให้วีโอไอพีโหลดไฟล์การกำหนดค่าทั้งหมดรวมเข้าด้วยกันแล้วรวมทั้งหมด / ทั่วโลกแล้วรวมเว็บไซต์ / ทั้งหมดแล้วรวมทั้งหมดนั้นลงในแต่ละโหนด / ร้านค้า ที่จะเกิดขึ้นสำหรับคำขอแต่ละครั้ง ด้วย 10k เว็บไซต์ที่คุณอาจจะมองหาที่นาทีของเวลานาฬิกาแขวนตามคำขอ
Kevin Schroeder

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

1
ปัญหาไม่ได้เป็น core_config_data ปัญหาคือว่าการกำหนดค่าร้านค้าจะถูกผสานจาก / เว็บไซต์ที่ผสานจาก / ทั่วโลกใน XML ฐานข้อมูลจะดีอย่างสมบูรณ์ มันเป็น PHP ที่จะเกลียดชีวิตเพราะการรวมกันของการกำหนดค่า ในขั้นตอนดีบักเกอร์ของคุณผ่าน Mage_Core_Model_Resource_Config :: loadToXml ให้ความสนใจเป็นพิเศษกับสาย 110 และต่อไปนี้
Kevin Schroeder

1
ตอนนี้กลับมาที่ตารางความจำของฉัน ข้อมูลแคชหมายถึงการจัดเก็บไว้ที่ไหนสักแห่งที่สามารถเข้าถึงได้อย่างรวดเร็ว วีโอไอพีเก็บข้อมูลการกำหนดค่าลงในวัตถุที่เป็นอนุกรม php - หากข้อมูลการกำหนดค่าของคุณมีขนาดใหญ่มากนั่นหมายความว่า PHP ต้องกำจัดข้อมูลจำนวนมากสำหรับทุกคำขอ หากคุณรู้วิธีใช้ xdebug ให้โปรไฟล์โหลดหน้าเว็บที่ช้าลงของคุณและดูว่าใช้เวลานานเท่าไรในการใช้งานฟังก์ชั่นunserialize : php.net/manual/en/function.unserialize.php - ถ้ามันมีขนาดใหญ่เกินกว่า 100ms "แคช" การกำหนดค่ากำลังทำลายระบบของคุณ
Gary Mort
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.