MODX क्रांति पर 13000+ उत्पादों के एक ऑनलाइन स्टोर का विकास। भाग 1

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

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

आज मैं MODX क्रांति पर बड़े ऑनलाइन स्टोर के विकास पर लेखों की एक श्रृंखला शुरू करना चाहता हूं, इन कहानियों के साथ कि आपको किन कठिनाइयों से निपटना है और इन समस्याओं को हल करने के लिए क्या विकल्प हैं। और इस तरह की समस्याओं को हल करने के लिए पहले से ही ShopModx बोर्ड पर क्या ले जाएगा, और क्या तरकीबें आपको ShopModx कोड में आए बिना अपने अनूठे स्टोर के विकास पर 100% नियंत्रण प्राप्त करने की अनुमति देगा।

इसलिए, उस स्टोर के बारे में थोड़ा जिसे हम काम कर रहे हैं: यह एक ऑनलाइन फर्नीचर स्टोर है। कल मैंने आधार आयात किया। यह 13,000+ दस्तावेज़, 43,000+ टीवी और modx_shopmodx_products में लगभग 13,000 प्रविष्टियाँ निकला।

मुझे तुरंत यह कहना होगा कि मुझे उम्मीद है कि पेज कोड को कैश से भी नहीं मिलेगा और 1 सेकंड से भी कम समय में मापदंडों द्वारा खोजा जाएगा, और औसत लोड 0.3-0.4 सेकंड से अधिक नहीं होना चाहिए।

तो, पहले समस्याओं और उनके समाधान के बारे में संक्षेप में बताएं।

समस्या 1. बड़ी कैश फ़ाइल और बहुत अधिक उपयोग की गई मेमोरी

आरंभ करने के लिए, शुद्ध रेवा के लिए इनपुट। मैंने विशेष रूप से शुद्ध 2.3.0 डाउनलोड किया और मेमोरी उपयोग को देखा। OnWebPageComplite इवेंट के लिए प्लगइन में अटका हुआ कोड - यह निकास के बाद MODX निष्पादन का सबसे चरम बिंदु है (), दस्तावेज़ कैश को सहेजना, आदि। पहला कॉल (मैन्युअल रूप से सभी कैश फ़ाइलों को हटा दिया गया):

Memory: 13.5409 Mb TotalTime: 0.1880 s 

अगला:

 Memory: 10.1396 Mb TotalTime: 0.0640 s 

वैसे, बस के मामले में, प्लगइन कोड है: gist.github.com/Fi1osof/5062419
आप इसे एक्सेस कंट्रोल के साथ संशोधित कर सकते हैं और सर्वर पर हमेशा वास्तविक लोड देख सकते हैं।

सामान्य तौर पर, हम स्टोर पर परिणामों की जांच करते हैं (वैसे, मैं तुरंत स्पष्ट करना चाहता हूं कि दस्तावेज़ खाली नहीं है, लेकिन 8 कनेक्टेड टीवी पैरामीटर हैं, जिनमें से एक कस्टम मीडिया संसाधन के साथ एक तस्वीर है)। पहला रन

 Memory: 24.1438 Mb TotalTime: 0.4360 s 

अगला:

 Memory: 18.4103 Mb TotalTime: 0.0960 s 

यही है, हमारे पास एक बार में लगभग 10 मीटर की उपयोग की गई मेमोरी में वृद्धि है। ऐसा इसलिए है क्योंकि हमने संदर्भ के URL के पूरे नक्शे को कैश कर लिया है, और हमारे पास वहां 13,000+ दस्तावेज़ हैं। संदर्भ कैश फ़ाइल लगभग 2 मीटर है।

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

 Memory: 16.1369 Mb TotalTime: 0.2640 s 

 Memory: 10.4021 Mb TotalTime: 0.0720 s 

अर्थात्, सामान्य मोड में, हम नंगे सिस्टम पर लगभग मेमोरी का उपभोग करते हैं।

समस्या 2. पृष्ठ नहीं मिला (404)

यह समस्या सीधे पिछले समाधान से उपजी है :-) जब से हमने URL के नक़्शे को काट दिया है, अब MODX "URL" का उपयोग करके यह नहीं समझ पाएगा कि हम किस URL का उपयोग कर रहे हैं। मैं तुरंत स्पष्ट कर दूंगा कि यदि आप सीएनसी का उपयोग नहीं करते हैं, तो यह आपके लिए समस्या नहीं होनी चाहिए (हालांकि आज कौन सीएनसी का उपयोग नहीं करता है?), या यदि आपके पास एक बड़ा स्टोर (1000 उत्पादों तक) नहीं है, तो आप पृष्ठ का नक्शा नहीं काटेंगे। , रैम का एक अतिरिक्त मेगाबाइट कोई समस्या नहीं है।

इसलिए, इस समस्या को हल करने के लिए, मैंने अपने स्वयं के राउटर का उपयोग करने का निर्णय लिया। मैंने अभी-अभी एक नया वर्ग लिखा है, जो मामूली है और थोड़े-थोड़े तरीकों से इसे टाल दिया। तर्क निम्नानुसार है: पृष्ठ तक पहुंचने के दौरान, MODX कैश में अनुरोधित URL द्वारा संसाधन आईडी खोजने की कोशिश करता है। (URL पहले ही साफ़ हो चुका है, यानी बिना किसी पैरामीटर के)। यदि यह पता चलता है, तो आईडी लौटाता है और फिर सब कुछ हमेशा की तरह होता है। यदि नहीं, तो uri द्वारा डेटाबेस में दस्तावेज़ खोजने की कोशिश करता है। ढूँढता है - कैश को आईडी लिखता है और फिर आईडी लौटाता है। यदि नहीं, तो मानक प्रक्रिया OnPageNotFound है (ताकि आप खोज को संशोधित करने के लिए अभी भी अपने प्लगइन में प्लग कर सकें)।

यह अतिरिक्त वर्ग shopModx के साथ आपूर्ति की जाएगी, और अगर किसी को इसकी आवश्यकता है (यदि कोई बड़ी दुकान है), तो बस इसे सेटिंग्स में चालू करें (modRequest.class key)।

सभी पेजों को तुरंत कैश करने का एक विकल्प भी है, उदाहरण के लिए, कैश को अपडेट करते समय (ऑनसाइटफ्रेश इवेंट के लिए प्लगइन का उपयोग करें)।

समस्या 3. कैश फ़ाइलों की एक बहुत

कल्पना करें कि कितने लोगों ने पिछले समाधान को पढ़ा है, और सोचा "ठीक है, क्या एक मूर्ख है!" :-)

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

मैंने रैम पर कैश तंत्र के पक्ष में अपनी पसंद का तर्क दिया कि कैश रीसेट सरल है। हार्ड ड्राइव से 1,000,000 फ़ाइलों को हटाने का प्रयास करें। यह sooooo लंबा होगा। मेमकाटेड के मामले में, कैश फ्लश करना सरल और त्वरित है।

 $modx->cacheManager->getCacheProvider()->flush(); 

मेमकास्ट का एक और विशाल प्लस यह है कि आप वस्तुओं सहित किसी भी प्रकार के डेटा को स्टोर कर सकते हैं। एकमात्र अपवाद संसाधन हैं (उदाहरण के लिए, डेटाबेस से कनेक्ट करना) और ऑब्जेक्ट जिनके गुणों में संसाधन शामिल हैं। ऐसी वस्तुओं को __sleep () और __wakeup () विधियों के साथ बनाया जाना चाहिए, ताकि बचत करने से पहले वे सभी संसाधन गुणों को हटा दें, और जब कैश से पुनर्स्थापित किया जाता है, तो वे इन गुणों को फिर से बना सकते हैं।

इसलिए परिणाम देखें। पहला रन

 Memory: 15.0709 Mb TotalTime: 0.1040 s 

आगे

 Memory: 10.403 Mb TotalTime: 0.0640 s 

मेरी राय में यह १३,०००+ दस्तावेजों के बिना पढ़े संदर्भ के लिए बहुत अच्छा है।

समस्या 4. सिस्टम सेटिंग्स बदलते समय दस्तावेजों का व्यापक अद्यतन

मैं क्यों नहीं समझाऊंगा, लेकिन मुझे कंटेनरों के प्रत्यय को बदलने की जरूरत थी। मैंने इसे बदल दिया, और मैंने अजाक्स प्रतिक्रिया का इंतजार नहीं किया ... यह प्रोसेसर / सिस्टम / सेटिंग्स / अपडेटफ्रेमग्रिड देखने के लिए उपयोगी था। इसमें एक ऐसा CheckForRefreshURIs () विधि है। सामान्य तौर पर, यदि "friendly_urls", "use_alias_path" या "container_suffix" बदल गया है, तो यह संकेत देता है कि URL को अपडेट करने की आवश्यकता है। सब सही है। लेकिन समस्या यह है कि वह सभी दस्तावेजों को अंधाधुंध रूप से अपडेट करने की कोशिश कर रहा है, कंटेनर भी नहीं। इसके अलावा, मेनूइन्डेक्स द्वारा छँटाई की स्थिति भी किसी कारण से जुड़ जाती है (हालाँकि हम नेस्टिंग ऑर्डर में रुचि रखते हैं, मेनू इंडेक्स में नहीं)।
सामान्य तौर पर, इस प्रक्रिया ने सर्वर को रोना बना दिया। जोड़ा गया हालत isfolder = 1 है, और फिर 6 सेकंड में सभी कंटेनरों को अपडेट किया है। अब मैं प्रत्यय नहीं बदलूंगा :-)

सारांश

व्यवहार में, हमें 13,000+ दस्तावेज़ों (दो तालिकाओं में) और 43000+ टीवी-शेक के साथ एक साइट पर एक दस्तावेज़ का पूर्ण प्रसंस्करण मिला, एक अद्यतन कैश के साथ 0.3 सेकंड से भी कम समय में। कैश से - 0.1 सेकंड से कम में।
सशर्त रूप से, हम मान सकते हैं कि इस स्तर पर एक बड़ी और छोटी साइट के बीच का अंतर समाप्त हो जाता है, क्योंकि आगे ब्रेक केवल पेज रेंडरिंग स्तर पर ही संभव है, और यह पहले से ही निर्भर करता है कि हम कैसे टेम्प्लेट लिखते हैं, आदि।
मैं इस बिंदु को अगले लेख (सबसे अधिक संभावना कल) में लिखूंगा। लेकिन मैं स्मार्टी पर जो कुछ भी करूंगा, उसे तुरंत ही कहूंगा, क्योंकि आईएमएचओ क्लीन चंक्स और स्निपेट्स पर यह सब कर रहा है।

और अंत में, 1000 अनुरोधों के साथ 100 ग्राहकों के एक स्थानीय परीक्षण के परिणाम: gist.github.com/Fi1osof/462e1af10ab7b95311df
अनुरोध के अनुसार समय: 44.224 [एमएस] (मतलब, सभी समवर्ती अनुरोधों के पार)

Modx.com पर PS पैकेज: modx.com/extras/package/shopmodx
गिटहब प्रोजेक्ट: github.com/Fi1osof/shopModx
अनुरोध वर्ग के साथ नवीनतम संस्करण भरा।

PPS मेमॉच्ड प्रदाता की सेटिंग्स को config.core.php में सीधे निर्दिष्ट करना बेहतर है (बस एक शब्द लें)।

 $config_options = array ( 'cache_handler' => 'cache.xPDOMemCached', 'cache_prefix' => 'shopmodx_', //          memcached- ); 

$ Config_options चर पहले से ही है।