Magento के स्वचालित कैशिंग इनसाइट

Question

हम मैग्नेटो ईई 1.11 को मेमेचेस के साथ चला रहे हैं। 2GB प्रति मेमरेस सर्वर, कुल 4GB। हमारे पास लगभग 240k उत्पाद हैं।

• उपलब्ध रैम: 6GB
• कोर: 16
• सूत्र: 32

यहां सौदा होता है, अधिक नए उत्पादों को जोड़ा जाता है और उत्पादों में बदलाव दैनिक आधार पर होता है और निश्चित रूप से हर बार जब कोई नया उत्पाद जोड़ा जाता है / बैक-एंड में संशोधित होता है तो कैश अमान्य हो जाता है, विशेष रूप से 'फुल पेज कैश'।

जब Magentos Auto Cache Generation को सक्षम किया जाता है तो कैश बनाने में लगभग 2 दिन लगते हैं, जिसमें क्रॉलर को 8 थ्रेड आवंटित किए जाते हैं। 2 दिनों के बाद मेम्कैच दो रैम डिस्क के बीच ~ 2GB अलग हो जाता है।

समस्या यह है कि जब उत्पादों को दैनिक आधार पर संशोधित किया जाता है तो कैश अमान्य हो जाता है और जैसे ही 'पूर्ण पृष्ठ कैश' ताज़ा होता है उन 2GB कैश को वर्ग 1, 0 पर वापस कर दिया जाता है और Magentos Auto cache का चिपचिपा चक्र फिर से शुरू हो जाता है। अब, न केवल कैश 0 पर वापस आ गया है, लेकिन सीपीयू का उपयोग 90% तक हो जाता है और वेबसाइट 5-10+ सेकंड के वेटिंग गेम में बदल जाती है और आप 100+ विविधताओं के साथ उत्पाद का अनुरोध करने की कोशिश कर सकते हैं, यदि यह है कैश नहीं यह पहली बार लोड करने में मिनट लगेंगे, यह हास्यास्पद है।

इसलिए, समुदाय के लिए मेरे प्रश्न।

• क्या मैगेंटो को कैश को स्वचालित रूप से "अपडेट" करने का एक तरीका है यदि अमान्य है, पूरे कैश को फिर से बनाए बिना और 0 से शुरू हो रहा है? मुझे पता है कि जब कैश को अमान्य कर दिया जाता है कि मैगेंटो जानता है कि किसी चीज़ को बदल दिया गया है, लेकिन कैश में बिल्कुल नहीं है (मुझे गलत होने पर सही करें)। क्या पूरे कैश को फिर से बनाने के लिए वहाँ मॉड्यूल / कॉन्फ़िगरेशन हैं?

साइड नोट पर, हम टिनी ब्रिक्स लाइटस्पीड मॉड्यूल का उपयोग कर रहे हैं।

• क्या Magentos Automatic Cache Generation को क्रोनजॉब से नियंत्रित किया जा सकता है? कहते हैं, 10pm - 6am पर क्रॉल करना शुरू करें।

• इस स्थिति को प्राप्त करने का सबसे अच्छा तरीका क्या होगा ?, जैसा कि आप समझते हैं कि हर दिन गीगाबाइट्स में कैश को पुनर्निर्माण करना सिर्फ स्वीकार्य नहीं है।

Comments

मुझे लगता है कि मैं अभी सर्वर के बारे में अधिक जानकारी पोस्ट करना चाहिए। जब मैंने प्रश्न पूछा तो मुझे सर्वर सेटअप से परिचित कराया गया था। लेकिन यहां वास्तविक सेटअप है: 2 सर्वर, समान। एक अपाचे एक MySQL चलाने वाले, दोनों 64GB RAM के साथ 2x AMD Opteron 6276 CPU पर 32 कोर, 32 थ्रेड्स के साथ बैठे हैं। बहुत बाद में, मैंने बहुत कुछ पढ़ा, जो सर्वर कॉन्फिगर के आसपास खोदा और महसूस किया कि बहुत सारी चीजें गलत थीं, खासकर मैजेंटोस कैश। उनके पास बैकएंड के रूप में 2GB APC सेटअप था और धीमी बैकएंड पर 1 + 1 कॉन्फिगरेशन और अन्य अजीब कॉन्फ़िगरेशन का एक गुच्छा के लिए 4GB मेमेक था।

— ओलेग

शायद इसलिए जब ईई के लिए स्विच बनाया गया था तो कैटलॉग का आकार बहुत छोटा था, निश्चित नहीं था। इसके अलावा, मुझे अभी भी यकीन नहीं है कि sql सर्वर सेटअप कैसे है क्योंकि मैंने एक्सेस के लिए नहीं पूछा है, फिर भी। तो मुझे यकीन है कि यह एक और पहेली है। मैं सिर्फ इतना कहना चाहता था कि उत्तर देने के लिए समय निकालने और महान अंतर्दृष्टि / संकेत प्रदान करने के लिए धन्यवाद देने के लिए सोनासी, हर बिट मदद करता है!

— ओलेग

जो लोग इस धागे के पार आते हैं, उनके लिए मैगेंटोस कैश स्थापित करने के लिए बहुत उपयोगी लिंक हैं: magebase.com/magento-tutorials/improving-the-file-cache-backend और especialy *** -> nbs -system.co.uk/ ब्लॉग -2 / magento-ऑप्टिमाइज़ेशन-howto-en.html प्लस को Magento Wiki और Magento व्हाइट पेज पढ़ना सुनिश्चित करें।

— ओलेग

Answer 1

आपके पास लगभग पर्याप्त रैम नहीं है

हमारे पास लगभग 240k उत्पाद
उपलब्ध हैं RAM: 6GB
धागे: 32

आपके पास उत्पादों की मात्रा के लिए लगभग पर्याप्त रैम नहीं है। अंगूठे के एक नियम के रूप में, हम कम से कम 2-4 जीबी रैम प्रति तार्किक कोर की सलाह देते हैं।

यदि आप अपने संभावित मेमोरी उपयोग को मैप करते हैं:

• 64 PHP धागे max_memory~ 768MB = 24GB के साथ
• 240,000 प्रोडक्ट्स का मतलब लगभग 15GB इनोबीडी टेबल स्पेस होगा
• 64 PHP थ्रेड्स 128 MySQL कनेक्शन के आसपास वारंट करेंगे, आमतौर पर यह न्यूनतम 200 एमबी प्रति कनेक्शन न्यूनतम लागत पर आता है
• Redis और lzfसंपीड़ित में 240,000 उत्पादों के लिए बैकएंड स्टोरेज - अभी भी लगभग 6GB RAM का उपभोग करेगा

तो कुल अब तक 70GB प्रतिबद्ध रैम है - हमने ओएस आदि का भी उल्लेख नहीं किया है।

आपका हार्डवेयर भयानक रूप से अनपेक्षित है । मैं सुझाव दूंगा कि इस मैगेंटो सर्वर पर लेख को कैसे प्रगति के लिए एक विचारक के एक बिट के लिए सेट करें।

Memcached कैश टैग का समर्थन नहीं करता है

यदि आप Memcached (कोई समस्या नहीं, इसका बहुत उच्च प्रदर्शन) का उपयोग कर रहे हैं, तो आप कैश टैग संग्रहीत कर रहे हैं या नहीं। यदि आपके पास slow_backendपरिभाषित नहीं है - तो आप टैग संग्रहीत नहीं कर रहे हैं, जिसका मूल अर्थ यह है कि आपका कैश किसी भी अलग कैश प्रकार के बीच भेदभाव नहीं कर सकता है - इसलिए आप उन्हें स्वतंत्र रूप से फ्लश नहीं कर पाएंगे।

इस पर एक लेख पढ़ें, http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/

हम दृढ़ता से रेडिस पर स्विच करने का सुझाव देंगे। इसमें इसकी क्विरक्स हैं और बड़े स्टोर्स के लिए महत्वपूर्ण फाइन-ट्यूनिंग की आवश्यकता है। लेकिन एक पूरे के रूप में कैश-टैग समर्थन के वास्तविक लाभ के साथ मेम्केड से थोड़ा बेहतर प्रदर्शन करेगा।

404 और एफपीसी

FPC में एक वास्तविक समस्या है, वास्तव में, सभी कैशिंग इंजनों में 404s की समस्या है। कारण, किसी भी पुराने URL को अभी भी क्रॉल या लिंक किया जा रहा है, एक ऐसे पेज पर उतरेगा जिसे पूरी core_url_rewriteतालिका के माध्यम से पुनरावृत्त करना है , कोशिश करें और अंत में 404 को लोड करने और लोड करने से पहले सभी परिभाषित राउटर और नेमस्पेस के खिलाफ मैच ढूंढें।

फिर एक ऐसे संसाधन का उपयोग करना, जिसका कोई मूल्य नहीं है और आपके कैश स्टोरेज में जगह की खपत करेगा। आपको शायद पता चलेगा कि आपके मेमकेच्ड स्टोरेज का एक बड़ा हिस्सा वास्तव में 404 सामग्री द्वारा खाया जा रहा है।

बड़े कैटलॉग (240k उत्पाद) के साथ, आप निश्चित रूप से उत्पाद कारोबार का अपना उचित हिस्सा लेने जा रहे हैं, और इस प्रकार, URL और उसके बाद, कई 404 में परिवर्तन होते हैं।

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>

क्रॉलर न चलाएं

यदि आपको पर्याप्त फुटफॉल मिला है - हम क्रॉल टूल चलाने की सलाह नहीं देते हैं, तो यह अनावश्यक भार उत्पन्न करता है। साइट ब्राउज़ करने वाले लोग / बॉट / क्रॉलर कैश को प्राइमेड रखें।

लेकिन अपने प्रश्न का उत्तर देने के लिए, यदि आप ऊपर उल्लिखित कॉन्फ़िगरेशन फ़ाइल में देखते हैं - आप क्रोन शेड्यूल को देखते हैं जिसे क्रॉल ब्राउज़िंग विंडो के लिए परिभाषित किया गया है।

यदि आप बासी सामग्री खरीद सकते हैं

और अंत में, यदि आपके पास पर्याप्त रैम है। FPC में संग्रहीत सामग्री के TTL को बढ़ाने से आपको अच्छा फायदा हो सकता है - अपने कैश्ड डेटा को अधिक समय तक जीवित रखने के लिए।

में <full_page_cache>में टैग को अपने ./app/etc/local.xmlबस को परिभाषित

<lifetimelimit>86400</lifetimelimit>

जीवनकाल सेकंड में परिभाषित किया गया है। आपको सामग्री की ताजगी, प्रदर्शन और आपके द्वारा वास्तव में उपलब्ध संग्रहण स्थान की मात्रा के बीच संतुलन बनाने की आवश्यकता है।

आप EE के साथ 3rd पार्टी कैशिंग एक्सटेंशन का उपयोग क्यों कर रहे हैं

आप एफपीसी के लिए एक प्रीमियम का भुगतान कर रहे हैं - जो मुझे कहने के लिए दर्द देता है, बहुत अच्छा है। तो आप शीर्ष पर 3 पार्टी विकल्प क्यों चला रहे हैं। इसे हटा दो।

इस तरह से रखो। यदि आपकी कार बुरी तरह से चल रही थी - क्या आप मुआवजे के लिए बूट में एक और इंजन जोड़ देंगे; या बस वहाँ पहले से ही इंजन को ठीक?

Answer 2

हम आपको अच्छी तरह से समझते हैं! हम हर दिन नए उत्पाद जोड़ते हैं या अपने उत्पादों को बदलते हैं और स्थिर ब्लॉकों को भी संशोधित करते हैं। इसलिए हम अमान्य Magento कैश और इस निरंतर सिस्टम -> कैश प्रबंधन के साथ भरे हुए थे। हमें अमान्य कैश प्रकारों को मैन्युअल रूप से ताज़ा करने की आवश्यकता से नफरत है।

फिर हमने नया Magento Optimizer एक्सटेंशन स्थापित किया । यह मॉड्यूल इस प्रक्रिया को स्वचालित करता है। यह अमान्य कैश / सभी कैश प्रकारों को ताज़ा करता है या निर्दिष्ट आवृत्ति पर Magento कैश स्टोरेज को फ्लश करता है। यह हमारी सभी टीम के लिए एक वास्तविक राहत थी!

इस एक्सटेंशन की एक और बड़ी विशेषता यह है कि यह सत्र फ़ाइलों और त्रुटि रिपोर्ट को साफ करता है जो X दिनों से अधिक पुरानी हैं। हर कोई जानता है कि var / सत्र और var / रिपोर्ट निर्देशिकाओं का आकार गीगाबाइट में बढ़ सकता है और इन फ़ाइलों की संख्या सौ से अधिक हो सकती है। इसलिए अब वेबसाइट के प्रदर्शन को धीमा करने के लिए, हमने एक बार Magento Optimizer सेट किया और इन निर्देशिकाओं के समय-समय पर ताज़ा करने के बारे में भूल गए।

मैगेंटो वर्तमान में एक छोड़ दिया कार्ट को विलय करने के लिए जाना जाता है जब ग्राहक लॉगिन करने की कोशिश करते हैं। ग्राहकों के अनुभव और दृष्टिकोण के प्रति वफादारी से, यह विनाशकारी है। Magento के ऑप्टिमाइज़र मॉड्यूल स्वचालित रूप से एक्स दिनों की पुरानी हो चुकी परित्यक्त गाड़ियों को हटा देता है। आप बिक्री के समय भी इस सुविधा का उपयोग कर सकते हैं और मौजूदा छोड़ी गई गाड़ियों के समय को सीमित कर सकते हैं।

Comments

जेम्स क्या आपका इस मॉड्यूल से कोई संबंध है? आप इसे लेकर उत्साहित हैं।

— परमहर