Magento Insight การแคชอัตโนมัติ

เรากำลังใช้ Magento EE 1.11 ด้วย memcache เซิร์ฟเวอร์ 2GB ต่อเซิร์ฟเวอร์รวม 4GB เรามีผลิตภัณฑ์ประมาณ 240k

• หน่วยความจำที่มีอยู่: 6GB
• แกน: 16
• หัวข้อ: 32

นี่คือข้อตกลงมีการเพิ่มผลิตภัณฑ์ใหม่และการเปลี่ยนแปลงผลิตภัณฑ์ที่เกิดขึ้นทุกวันและแน่นอนทุกครั้งที่มีการเพิ่ม / แก้ไขผลิตภัณฑ์ใหม่ในส่วนหลังแคชจะกลายเป็นโมฆะโดยเฉพาะ 'แคชหน้าเต็ม'

เมื่อเปิดใช้งานการสร้างแคชอัตโนมัติของ Magentos จะใช้เวลาประมาณ 2 วันในการสร้างแคชโดยมี 8 เธรดที่จัดสรรให้กับโปรแกรมรวบรวมข้อมูล หลังจาก 2 วัน memcache จะลอยอยู่รอบ ๆ ~ 2GB คั่นระหว่าง ram ทั้งสองแผ่น

ปัญหาคือเมื่อผลิตภัณฑ์ได้รับการแก้ไขทุกวันแคชจะไม่สามารถใช้งานได้และทันทีที่ 'แคชหน้าเต็ม' ถูกรีเฟรชแคช 2GB นั้นกลับไปเป็นสี่เหลี่ยมจัตุรัส 1, 0 และวงจรหนืดของ Magentos Auto เริ่มทำงานอีกครั้ง ตอนนี้ไม่เพียง แต่แคชกลับเป็น 0 แต่การใช้งาน CPU เพิ่มขึ้น 90% และเว็บไซต์กลายเป็นเกมรอประมาณ 5-10 วินาทีและคุณสามารถลืมที่จะลองขอผลิตภัณฑ์ที่มีรูปแบบมากกว่า 100 รูปแบบได้ ไม่แคชจะใช้เวลาไม่กี่นาทีในการโหลดครั้งแรกมันไร้สาระ

ดังนั้นคำถามของฉันกับชุมชน

• Magento มีวิธีการ "อัปเดต" แคชโดยอัตโนมัติหรือไม่หากไม่ถูกต้องโดยไม่ต้องสร้างแคชใหม่ทั้งหมดและเริ่มต้นจาก 0 ฉันรู้ว่าเมื่อใดที่แคชไม่ถูกต้องว่าวีโอไอพีรู้ว่ามีการเปลี่ยนแปลงบางอย่าง แต่ไม่ว่าจะอยู่ที่ไหนในแคช (แก้ไขฉันถ้าฉันผิด) มีโมดูล / การกำหนดค่าเพื่อหลีกเลี่ยงการสร้างแคชใหม่ทั้งหมดหรือไม่

ในบันทึกด้านข้างเรากำลังใช้โมดูล Tiny Bricks LightSpeed

• Magentos Automatic Cache Generation สามารถควบคุมเวลาด้วย cronjob ได้หรือไม่? พูดเพื่อเริ่มรวบรวมข้อมูลเวลา 22.00 น. - 18.00 น.

• อะไรจะเป็นวิธีที่ดีที่สุดในการเข้าถึงสถานการณ์นี้? ในขณะที่คุณเข้าใจว่าการสร้างแคชที่มีหน่วยเป็นกิกะไบต์ทุกวันนั้นไม่เป็นที่ยอมรับ

คุณมี RAM ไม่เพียงพอ

เรามีผลิตภัณฑ์ประมาณ 240k
ram ที่มีจำหน่าย: 6GB
หัวข้อ: 32

คุณมี RAM ไม่เพียงพอสำหรับจำนวนผลิตภัณฑ์ที่คุณมี ตามกฎทั่วไปเราขอแนะนำ RAM อย่างน้อย 2-4GB ต่อตรรกะหลัก

หากคุณจับคู่การใช้หน่วยความจำที่เป็นไปได้:

• 64 เธรด PHP ที่มีmax_memory~ 768MB = 24GB
• มีแนวโน้มว่าผลิตภัณฑ์ 240,000 รายการจะหมายถึงพื้นที่ตาราง InnoDB ประมาณ 15GB
• 64 เธรด PHP จะรับประกันการเชื่อมต่อ MySQL ประมาณ 128 ครั้งโดยทั่วไปจะมีค่าใช้จ่ายประมาณ 200MB ต่อการเชื่อมต่อขั้นต่ำ
• พื้นที่เก็บข้อมูลเบื้องหลังสำหรับ 240,000 ผลิตภัณฑ์ใน Redis และlzfบีบอัด - จะยังคงใช้ RAM ประมาณ 6GB

ดังนั้นทั้งหมดจนถึงขณะนี้คือ RAM 70GB ที่ได้รับมอบหมาย - เราไม่ได้กล่าวถึงระบบปฏิบัติการอื่น ๆ

ฮาร์ดแวร์ของคุณมีการระบุขีดล่างอย่างน่ากลัว ฉันขอแนะนำให้อ่านบทความเซ็ตอัพเซิร์ฟเวอร์ของ Magentoเพื่อรับความรู้สึกเกี่ยวกับวิธีการดำเนินการ

Memcached ไม่รองรับแท็กแคช

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

มีการอ่านมากกว่านี้http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/

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

404's และ FPC

FPC มีปัญหาจริงอันที่จริงแล้วเอ็นจิ้นแคชทั้งหมดมีปัญหากับยุค 404 เหตุผลที่ URL เก่า ๆ ที่ยังคงมีการรวบรวมข้อมูลหรือเชื่อมโยงไปถึงนั้นจะเชื่อมโยงไปถึงหน้าเว็บที่ต้องวนซ้ำทั้งcore_url_rewriteตารางลองค้นหาการจับคู่กับเราเตอร์และเนมสเปซที่กำหนดไว้ทั้งหมดก่อนจะยอมแพ้และโหลด 404

จากนั้นแคชทรัพยากรที่ไม่มีค่าและจะใช้พื้นที่ในที่เก็บแคชของคุณ คุณอาจจะพบว่าพื้นที่จัดเก็บ Memcached ของคุณมีขนาดใหญ่มากโดยมีเนื้อหาอยู่ที่ 404 รายการ

ด้วยแคตตาล็อกขนาดใหญ่ (240k ผลิตภัณฑ์) แน่นอนว่าคุณจะมีส่วนแบ่งที่ยุติธรรมของการหมุนเวียนสินค้าดังนั้นการเปลี่ยนแปลงใน URL และต่อมา 404 หลายแห่ง

FPC เป็นโมฆะกับสะอาด

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

นี่คือแพทช์ด่วนเพื่อให้คุณมีความคิดในการแก้ปัญหาของคุณ

app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
             <observers>
                 <enterprise_pagecache>
                     <class>enterprise_pagecache/observer</class>
-                    <method>cleanCache</method>
+                    <method>invalidateCache</method>
                 </enterprise_pagecache>
             </observers>
         </catalogrule_after_apply>

อย่าเรียกใช้โปรแกรมรวบรวมข้อมูล

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

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

หากคุณสามารถจ่ายเนื้อหาค้าง

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

ใน<full_page_cache>แท็กที่คุณ./app/etc/local.xmlเพิ่งกำหนด

<lifetimelimit>86400</lifetimelimit>

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

เหตุใดคุณจึงใช้ส่วนขยายแคชบุคคลที่สามกับ EE

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

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

เราเข้าใจคุณดีมาก! เราเพิ่มใหม่หรือเปลี่ยนผลิตภัณฑ์ของเราทุกวันและปรับเปลี่ยนบล็อกคงที่เช่นกัน ดังนั้นเราจึงเต็มไปด้วยแคช Magento ที่ไม่ถูกต้องและค่าคงที่นี้คือ System -> Cache Management เราเกลียดความจำเป็นในการรีเฟรชประเภทแคชที่ไม่ถูกต้องด้วยตนเอง

จากนั้นเราติดตั้งส่วนเสริม Magento Optimizerใหม่ โมดูลนี้ทำกระบวนการนี้โดยอัตโนมัติ มันรีเฟรชที่ไม่ถูกต้อง / ทุกประเภทแคชหรือล้างหน่วยเก็บแคช Magento ที่ความถี่ที่ระบุ มันเป็นความผ่อนคลายอย่างแท้จริงสำหรับทีมของเราทุกคน!

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

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