डेटा कैशिंग, शायद आखिरी चीज जो आपको उपयोग करनी चाहिए

हाल ही में, मैंने ई-कॉमर्स के लिए लोकप्रिय PHP पैकेज के साथ एक बल्कि गर्म संघर्ष किया था। नतीजतन, मैं वेब अनुप्रयोगों की वास्तुकला में एक सामान्य गलती के बारे में बात करना चाहता था।

यह क्या गलती है?

जिस पैकेज पर मैंने काम किया, वह भारी कैशिंग के साथ काम करता था। यह प्रति सेकंड 10 से अधिक पृष्ठ नहीं दे सकता था, अगर कुछ "वैकल्पिक" कैश सेटिंग्स शामिल नहीं थीं। जाहिर है, ऐसे प्रदर्शन के साथ, वे वास्तव में वैकल्पिक नहीं हैं, लेकिन अनिवार्य हैं।



मुझे लगता है कि जब आपके पास मेमस्कैड के रूप में ऐसा अद्भुत उपकरण है, तो आप किसी भी प्रदर्शन समस्या को हल करने के लिए इसका उपयोग करना चाहते हैं। लेकिन कई मामलों में, यह पहला उपकरण नहीं होना चाहिए जिसे आप उपयोग करने की कोशिश कर रहे हैं। और यहाँ क्यों है:



- कैशिंग सभी उपयोगकर्ताओं के लिए काम नहीं कर सकता है। - आप पृष्ठ को खोलते हैं - यह जल्दी से लोड होता है। लेकिन क्या यह सभी उपयोगकर्ताओं के लिए सही है? कैशिंग बहुत बार आपको अधिकांश आगंतुकों के लिए लोडिंग समय का अनुकूलन करने की अनुमति देता है, लेकिन अक्सर वास्तविकता में आपको अपवाद के बिना (यदि आप छह सिग्मा सिद्धांत का पालन करते हैं) पेज को सभी के लिए जल्दी से लोड करने की आवश्यकता है। व्यवहार में, एक अनुरोध हमेशा एक ही उपयोगकर्ता के लिए कैश को याद कर सकता है, जो आगे की स्थिति को बढ़ाता है। ( अनुवादक का नोट : मुझे एक बहुत ही वास्तविक मामला पता है जब कैश ने 99% उपयोगकर्ताओं के लिए इलेक्ट्रॉनिक स्टोर में काम किया और 1% आगंतुकों के लिए काम नहीं किया था जिनके पास था एक लंबा खरीदारी का इतिहास, परिणामस्वरूप, दुकान ने धीरे-धीरे सक्रिय खरीदारों के लिए काम किया)।



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



- वास्तव में कैश को प्रबंधित करना एक आसान काम नहीं है - क्या आपने कभी " रनवे कैश " के साथ संघर्ष किया है या ऐसी स्थिति के साथ जहां एक ही समय में बड़ी संख्या में कैश तत्व अक्षम हैं?

वैकल्पिक दृष्टिकोण

कैशिंग को एक बोझ के रूप में देखा जाना चाहिए जिसके बिना कई अनुप्रयोग नहीं रह सकते। जब तक आप आसानी से लागू अनुकूलन विधियों के पूरे शस्त्रागार को समाप्त नहीं कर लेते, तब तक आपको इस बोझ से बचने की कोशिश करनी चाहिए।

ये तरीके क्या हैं?

अनुकूलन में प्रवेश करने से पहले, सुनिश्चित करें कि आप इस सरल सूची से गुज़रे हैं:



- क्या आप प्रत्येक अनुरोध के लिए निष्पादन योजना को समझते हैं? यदि नहीं, तो long_query_time = 0 सेट करें और प्रश्नों की पूरी सूची प्राप्त करने के लिए mk-query-digest कमांड का उपयोग करें। उनमें से प्रत्येक के लिए निष्पादित करें, निष्पादन योजना का विश्लेषण करें।



- क्या आप सेलेक्ट * का उपयोग करते हैं तो केवल कॉलम के एक छोटे सेट का उपयोग करें? या आप डेटाबेस से कई पंक्तियों का चयन करते हैं, लेकिन उनमें से कुछ का ही उपयोग करते हैं? यदि ऐसा है, तो आप बहुत अधिक डेटा का चयन करते हैं, डीबीएमएस स्तर के अनुकूलन को सीमित करते हैं, जैसे कि अनुक्रमणिका का उपयोग।



- क्या आप जानते हैं कि एक पेज बनाने के लिए आप कितने प्रश्नों का उपयोग करते हैं? क्या वे सभी वास्तव में आवश्यक हैं? क्या इनमें से कुछ अनुरोधों को एकल अनुरोध में बदलना या उन्हें पूरी तरह से हटाना संभव है? ( अनुवादक का ध्यान दें : एक बहुत ही सामान्य समस्या। मुझे वास्तव में उस मामले का पता है जब पृष्ठ ने कक्षा में छात्रों की एक सूची प्रदर्शित की, और फिर प्रत्येक छात्र के लिए चक्र में कक्षा के नाम सहित अतिरिक्त जानकारी का अनुरोध किया गया था। परिवर्तन के बाद, अनुरोधों की संख्या 61 से घटाकर 3 कर दी गई थी)।



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



दीर्घकालिक दृष्टिकोण से, कई अनुप्रयोगों को वास्तुकला को सरल रखना चाहिए और समस्याओं को हल करने के लिए प्रलोभन में नहीं देना चाहिए "जैसे असली लड़के करते हैं।"



लगभग। अनुवादक : बहुत वास्तविक संवाद बहुत पहले नहीं:

- इसलिए हमें प्रदर्शन की समस्याएं हैं, हमें लॉगिन के लिए कैशिंग, वर्टिकल पार्टीशन और NoSQL DB को जोड़ना होगा

- दोस्तों - मैंने यहां देखा - 4,000 पंक्तियों के लिए आपके पास एक फुलस्कैन क्वेरी है, मैंने एक इंडेक्स बनाने की कोशिश की, सब कुछ 26 बार त्वरित हुआ।



अनुवाद पर कुछ नोट्स



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

2. मैं इस तथ्य पर ध्यान आकर्षित करना चाहता हूं कि लेख यह नहीं कहता है कि डेटा को कैश करना आवश्यक नहीं है। उन्हें कैश करने की आवश्यकता है, लेकिन डेटाबेस प्रश्नों को अनुकूलित करने के कुछ सरल तरीके आज़माने के बाद ही। दूसरे शब्दों में, आपको एक साधारण से शुरुआत करने की आवश्यकता है।