कैसे हमने द्रुपल वाणिज्य में तेजी लाई

विस्मयादिबोधक: अगर सब कुछ जो नीचे लिखा गया है, आपको लगता है कि "बेबी टॉक" और बहुत स्पष्ट चीजें हैं, तो हम आपके साथ काम करके खुश होंगे :)



पृष्ठभूमि: लगभग एक साल पहले, हमारे छोटे लेकिन गर्वित वेब स्टूडियो को एक ऑनलाइन स्टोर प्रिंटर38.ru विकसित करने का आदेश मिला। और जब से हम सीएमएस ड्रुपल में विशेषज्ञ हैं, हमने ड्रुपल कॉमर्स का उपयोग ऑनलाइन स्टोर मॉड्यूल के रूप में करने का फैसला किया।



जो लोग इसमें रुचि रखते हैं कि कैटलॉग के एक पृष्ठ को लोड करने में हमें 5 मिनट क्यों लगे, और हम इसे कैसे पार कर पाए, बिल्ली के नीचे स्वागत है।





यदि आपने कभी यैंडेक्स मार्केट के माध्यम से एक प्रिंटर उठाया है, तो आपको समान उत्पादों के लिए फ़ील्ड की संख्या का प्रतिनिधित्व करना चाहिए। हमारे पास डेटाबेस में हर उत्पाद की विशेषताओं के साथ 184 क्षेत्र हैं - प्रिंट गति से लेकर बैटरी जीवन की उपलब्धता तक।







यहाँ मुझे CMS Drupal की एक विशेषता के बारे में कहना चाहिए - प्रत्येक क्षेत्र के लिए डेटाबेस में एक अलग तालिका बनाई गई है। बहुमुखी प्रतिभा के लिए भुगतान करें, जो भी आप चाहते हैं ...

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



पहली बार हमने दृश्य बनाए, जो ईमानदारी से सभी फ़िल्टर फ़ील्ड प्रदर्शित करते थे, हम लोड करने के लिए मुख्य पृष्ठ की प्रतीक्षा करने में सक्षम नहीं थे। और यह इस तथ्य के बावजूद कि साइट बहुत अच्छी विशेषताओं के साथ एक अलग सर्वर पर चलती है।



क्लासिक "डांसिंग विद ए टैम्बूरिन" शुरू हुआ - MySQL ऑप्टिमाइज़ेशन, क्वेरी कैशिंग, हार्ड डिबगिंग और प्रोफाइलिंग :)

मैं इस पोस्ट में अनुकूलन क्रियाओं के अनुक्रम को पुनर्स्थापित करने का प्रयास करूंगा, जिसके परिणामस्वरूप हम साइट पर पृष्ठों को लोड करने के लिए एक स्वीकार्य गति प्राप्त करने में सक्षम थे।

1. मेमेच्ड मॉड्यूल को जोड़ना

द्रुपाल के निर्देशन में किसी भी "किक" के लिए - वे कहते हैं कि यह धीरे-धीरे काम करता है - इसके प्रचारक "कैश का उपयोग करें" का जवाब देते हैं। दरअसल, यह किया गया था।

Drupal standard caching, जैसा कि आप जानते हैं, कैश को उसी डेटाबेस में सेव करता है, जो हमारे मामले में शुरू में बेकार था।

इसलिए, कैश को रैम में रखने का निर्णय लिया गया - सौभाग्य से, यह हमारे सर्वर पर पर्याप्त था। इस प्रयोजन के लिए, उन्होंने ड्रुपल में सर्वर और मेमकेच_स्टोरेज का उपयोग किया ( अद्भुत मॉड्यूल के लिए यूजीन स्पलेस्का के लिए धन्यवाद)।



डेटा को कैश में स्थानांतरित करने के बाद, सब कुछ तेजी से आगे बढ़ना शुरू हो गया, लेकिन फिर भी जिस तरह से मैं चाहता था वह नहीं था। हम आगे समझते हैं ...

2. मेमेकैड में फॉर्म कैश को निकालना

एक दिन बादल, हमने कैश_फॉर्म टेबल के कुछ अमानवीय आकार को देखा - 7 जीबी से अधिक! टेबल को साफ किया गया था, हालांकि, यह फिर से बिजली की गति से बढ़ने लगा।



कारण सरल था: हमारे उत्पाद सूची में प्रत्येक "खरीदें" बटन एक छोटा रूप है जिसे ड्रुपल कैश के लिए आवश्यक मानते हैं, जबकि एक साथ "जो भी हाथ में आता है" को खींचते हैं। और जब AJAX बटन (हमारे मामले में) का उपयोग करते हैं, तो कैश तेजी से परिमाण के क्रम को बढ़ने लगता है । इसके अलावा, केवल कुछ Drupal के नेतृत्व वाले डेवलपर्स के लिए, cache_form तालिका को स्वचालित रूप से साफ़ नहीं किया जाता है, जैसा कि अन्य कैश तालिकाओं के साथ होता है।



समस्या को समझने का मतलब है इसे 90% हल करना :)

कैश_फॉर्म को मेमकाटेड (डेटाबेस में इसे स्टोर करने के लिए सिफारिशों के विपरीत) में भी प्रदान किया गया था।

आवर्त सारणी की सफाई के लिए हमने अनुकूलित मॉड्यूल का उपयोग किया (अब हम इसे ड्रुपल कॉमर्स के साथ सभी साइटों पर डिफ़ॉल्ट रूप से डालते हैं)।

Xandeadx ने AJAX बटन के साथ समस्या को हल किया , लेकिन इसका समाधान मेरे द्वारा बताए गए चरणों के कुछ महीने बाद ही दिखाई दिया, इसलिए उस समय हम अपने प्रोजेक्ट में इसका उपयोग नहीं कर सके। ;)



साइट का मुख्य पृष्ठ "उड़ना" शुरू हुआ। हालांकि, कैटलॉग अभी भी परेशानी में है - पेज 2-3 मिनट के लिए खुलता है। :(

3. विचारों में क्षेत्रों की विफलता

दोस्तों, जैसा कि हमारे सबसे अनुभवी डेवलपर ने कहा, “हम सभी जानते हैं कि ड्रुपल कैश नोड्स है। तो हम इसका उपयोग क्यों नहीं करते हैं, और हर बार जब हम विचार करते हैं, तो डेटाबेस से सभी डेटा खींच लेते हैं? "



जल्दी से नहीं कहा। कुछ 1-2 घंटे टीम के काम को देखने और पृष्ठ को मोड़ने पर काम करते हैं, और, लो और निहारना, कैटलॉग पृष्ठ के लोडिंग को "कुछ" 40-50 सेकंड तक कम करने में कामयाब रहे। उपयोगकर्ता इंतजार करेंगे, है ना? वे जल्दी करने के लिए कहीं नहीं है ...

4. एक और अनुकूलन का प्रयास - मानक पैगिनेटर को त्यागना, कैशिंग को "दृश्य" में जोड़ना, कैशिंग संस्थाओं

तब प्रोग्रामरों को फिर से कैबिनेट से टैम्बोरिन मिला (सौभाग्य से, उन्होंने इसे दूर करने का प्रबंधन नहीं किया)।



स्मार्ट लोगों ने पढ़ा है कि "ब्रेक" की समस्या एक मानक पेजर (उर्फ पेजिनेटर, उर्फ ​​पेजिंग) हो सकती है। मॉड्यूल views_litepager स्थापित करके ठीक किया गया।



उसी समय, हमने कॉमर्स_ेंटिटी कैश मॉड्यूल स्थापित किया है, जो उत्पाद ऑब्जेक्ट की इकाई (एस) को कैश करना चाहिए।



हालांकि, इन सभी "नृत्यों" ने गति में केवल एक छोटी वृद्धि दी।







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



पृष्ठ निष्पादन समय 69728.43 एमएस था

हम्म ...

6. लगभग एक जीत। मैनुअल क्वेरी अनुरोध अनुकूलन

एक निश्चित बिंदु पर, हमने महसूस किया कि कठोर तरीकों के साथ कार्य करने का समय आ गया है। अर्थात् - विस्तार से अध्ययन करने के लिए कि डेटाबेस में वास्तव में इस तरह के विचार क्या कहते हैं, कि परिणाम उत्पन्न करने में कम से कम 30 सेकंड लगते हैं।



और हमने कुछ इस तरह देखा:

... INNER JOIN {commerce_product} commerce_product_field_data_field_product_reference ON field_data_field_product_reference.field_product_reference_product_id = commerce_product_field_data_field_product_reference.product_id INNER JOIN {field_data_commerce_price} commerce_product_field_data_field_product_reference__field_data_commerce_price ON commerce_product_field_data_field_product_reference.product_id = commerce_product_field_data_field_product_reference__field_data_commerce_price.entity_id AND ( commerce_product_field_data_field_product_reference__field_data_commerce_price.entity_type = 'commerce_product' AND commerce_product_field_data_field_product_reference__field_data_commerce_price.deleted = '0' ) INNER JOIN {field_data_field_printer_a4_speed_2} commerce_product_field_data_field_product_reference__field_data_field_printer_a4_speed_2 ON commerce_product_field_data_field_product_reference.product_id = commerce_product_field_data_field_product_reference__field_data_field_printer_a4_speed_2.entity_id AND ( commerce_product_field_data_field_product_reference__field_data_field_printer_a4_speed_2.entity_type = 'commerce_product' AND commerce_product_field_data_field_product_reference__field_data_field_printer_a4_speed_2.deleted = '0' ) ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

और इसलिए - छानने में शामिल प्रत्येक क्षेत्र के लिए।

हां, बहुत सारे जोइन हैं। लेकिन वे एसओ लंबे समय तक काम नहीं कर सकते हैं!

“रुको, हमें एक प्रकार की जांच की आवश्यकता क्यों है? हमारे पास उत्पाद आईडी के साथ सभी इकाइयाँ होनी चाहिए जो 'Commerce_product' हैं? "



आईडीई को अपने हाथों में लेते हुए, हम अपने मॉड्यूल में एक छोटा हुक लिखते हैं:

 /** * Implementation of hook_views_query_alter * @param type $view * @param type $query */ function mymodule_views_query_alter(&$view, &$query) { if ($view->name == 'catalog_v_2') { foreach ($query->table_queue as $key=>$item) { $query->table_queue[$key]['join']->extra=array(); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यह है, हम बस JOIN से सभी अतिरिक्त शर्तों को "बाहर फेंक" (समझ से बाहर हटाए गए, जो हमारे अनुभव में, हमेशा शून्य है)।

कम से कम एक जोइन से पूरी तरह से छुटकारा पाना संभव था, लेकिन यह पहले से ही देर रात था, और हर कोई सोना चाहता था :)



के तुलना करते हैं:



पहले: 34665.211 मि

के बाद: 0.13 मि



हां, "पूर्णता की कोई सीमा नहीं है", इसलिए हम अनुकूलन पर प्रयोग जारी रखते हैं। हमें उम्मीद है कि हमारा अनुभव किसी के लिए उपयोगी होगा, और Drupal वाणिज्य पर कई सुविधाजनक और तेज़ ऑनलाइन स्टोर पैदा होंगे :)