संयोजन कैश विधियों - memcache/disk आधारित

Question

यह सौदा है। हम प्रदर्शन मुद्दों को हल करने के लिए पूरी स्थिर एचटीएमएल सड़क ले लेते थे, लेकिन चूंकि साइट आंशिक रूप से गतिशील होगी, यह हमारे लिए काम नहीं करेगी। हमने इसके बारे में सोचा है कि PHP को तेज़ करने और सबसे अधिक उपयोग किए जाने वाले डेटा के लिए कैशिंग का ख्याल रखने के लिए memcache + eAccelerator का उपयोग कर रहा है। पर मेम्कैश का प्रयोग >> सभी < < प्रमुख प्रश्नों और इसे अकेले छोड़ने यह क्या करता है क्या करने के लिए सबसे अच्छा

• :

  यहाँ हमारे दो दृष्टिकोण है कि हम अभी के बारे में सोचा है है।

• अधिकतर पुनर्प्राप्त डेटा के लिए Usinc memcache, और आगे के उपयोग के लिए मानक हार्डड्राइव-संग्रहीत कैश के साथ संयोजन।

केवल memcache का उपयोग करने का मुख्य लाभ प्रदर्शन का है, लेकिन जैसे ही उपयोगकर्ता बढ़ते हैं, स्मृति उपयोग भारी हो जाता है। प्रदर्शन में सैद्धांतिक समझौता होने के बावजूद, दोनों आवाज़ों को हमारे लिए अधिक प्राकृतिक दृष्टिकोण की तरह जोड़ना। मेमकैड में कुछ प्रतिकृति सुविधाएं भी उपलब्ध हैं, जो नोड्स को बढ़ाने का समय होने पर आसान हो सकती हैं।

हमें किस दृष्टिकोण का उपयोग करना चाहिए? - क्या यह दो तरीकों से समझौता करने और गठबंधन करने के लिए बेवकूफ है? क्या हमें memcache का उपयोग करने पर ध्यान देना चाहिए और इसके बजाय स्मृति को अपग्रेड करने पर ध्यान देना चाहिए क्योंकि लोड की संख्या उपयोगकर्ताओं के साथ बढ़ जाती है?

बहुत बहुत धन्यवाद!

Answer 1

समझौता और गठबंधन इन दो विधि एक बहुत चालाक तरीका है, मुझे लगता है।

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

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

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

असल में वहाँ एक शांत विधि, जिसमें आप टैग आधारित कैश ट्रैकिंग (memcached-tag उदाहरण के लिए) करने की अनुमति देता है। यह हुड के नीचे बहुत आसान है। प्रत्येक कैश एंट्री के साथ आप टैग संस्करणों का वेक्टर सहेजते हैं, जो यह संबंधित है (उदाहरण के लिए: {directory#5: 1, user#8: 2})। जब आप कैश लाइन पढ़ते हैं तो आप memcached से सभी वास्तविक वेक्टर नंबर भी पढ़ते हैं (यह multiget के साथ प्रभावी ढंग से किया जा सकता है)। यदि कैश लाइन में सहेजे गए टैग संस्करण से कम से कम एक वास्तविक टैग संस्करण अधिक है तो कैश को अमान्य कर दिया गया है। और जब आप ऑब्जेक्ट्स बदलते हैं (उदाहरण के लिए निर्देशिका) उचित टैग संस्करण को बढ़ाया जाना चाहिए। यह बहुत ही सरल और शक्तिशाली विधि है, लेकिन इसके अपने नुकसान हैं, हालांकि। इस योजना में आप कुशल कैश अमान्यता निष्पादित नहीं कर सके। Memcached आसानी से लाइव प्रविष्टियों को छोड़ सकते हैं और पुरानी प्रविष्टियां रख सकते हैं।

और हां आप को याद रखना चाहिए की: "वहाँ कंप्यूटर विज्ञान में केवल दो हार्ड चीजें हैं: कैश अमान्यकरण और नामकरण बातें" - फिल Karlton।

Answer 2

मैं सुझाव दूंगा कि आप पहले सभी प्रमुख प्रश्नों के लिए memcache का उपयोग करें। फिर, कम से कम उपयोग किए जाने वाले प्रश्नों को ढूंढने के लिए परीक्षण करें या डेटा जो शायद ही कभी बदला जाता है और फिर इसके लिए कैश प्रदान करें।

यदि आप शायद ही कभी इस्तेमाल किए गए डेटा से सामान्य डेटा को अलग कर सकते हैं, तो आप अधिक सामान्य रूप से उपयोग किए गए डेटा पर प्रदर्शन में सुधार करने पर ध्यान केंद्रित कर सकते हैं।

Answer 3

आप ओएस में डिस्क/मेमोरी कैश के संयोजन को प्रतिनिधि कर सकते हैं (यदि आपका ओएस पर्याप्त स्मार्ट है)। सोलारिस के लिए, आप वास्तव में बीच में भी एसएसडी परत जोड़ सकते हैं; इस तकनीक को एल 2एआरसी कहा जाता है।

मैं एक शुरुआत के लिए यह पढ़ने के लिए सलाह देते हैं: http://blogs.oracle.com/brendan/entry/test।

Answer 4

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

एक ही समय में

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

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

Answer 5

मेमकैड ऐसा कुछ है जिसका उपयोग आप करते हैं जब आप सुनिश्चित करते हैं कि आपको आवश्यकता है। आप स्मृति पर भारी होने की चिंता नहीं करते हैं, क्योंकि जब आप इसका मूल्यांकन करते हैं, तो आप समर्पित बॉक्स की लागत शामिल करते हैं जिन्हें आप इसे तैनात करने जा रहे हैं। के रूप में अपनी स्मृति बेहतर इस्तेमाल किया कैशिंग और जो कुछ भी यह बजाय करता होगा

एक साझा मशीन पर memcached डाल ज्यादातर मामलों में, समय की बर्बादी है।

memcached का लाभ यह है कि आप कई मशीनों के बीच एक साझा कैश, जो हिट दर बढ़ जाती है के रूप में उपयोग कर सकते हैं।इसके अलावा, आप एक बॉक्स के मुकाबले कैश आकार और प्रदर्शन कर सकते हैं, क्योंकि आप कई बॉक्स (प्रति भौगोलिक स्थान) को तैनात कर सकते हैं (और सामान्य रूप से)।

जिस तरह से आमतौर पर memcached का उपयोग किया जाता है वह आपके ऐप सर्वर से कम विलंबता लिंक पर निर्भर करता है; ताकि आप सामान्य रूप से अपने बुनियादी ढांचे के भीतर विभिन्न भौगोलिक स्थानों में एक ही memcached क्लस्टर का उपयोग नहीं होता है (प्रत्येक डीसी अपने स्वयं के क्लस्टर के लिए होता है)

प्रक्रिया है:

1. प्रदर्शन की समस्याओं को पहचानें
2. फैसला कितना प्रदर्शन सुधार पर्याप्त है
3. आवश्यक परीक्षण मशीनों के साथ उत्पादन-ग्रेड हार्डवेयर पर, अपनी परीक्षण प्रयोगशाला में समस्याएं पुन: उत्पन्न करें - यह अनौपचारिक है और आपको अपने ऐप को पर्याप्त रूप से चलाने के लिए बहुत से समर्पित (यहां तक ​​कि विशेष) हार्डवेयर की आवश्यकता हो सकती है।
4. एक प्रस्तावित समाधान का परीक्षण करें
5. यदि यह काम करता है, तो इसे उत्पादन में छोड़ दें, यदि नहीं, तो अधिक विकल्प आज़माएं और फिर से शुरू करें।

आप नहीं

• कैश "सब कुछ"
• उनकी वास्तविक प्रभाव को मापने के बिना बातें करना चाहिए।

अपने प्रदर्शन परीक्षण वातावरण परिपूर्ण नहीं होगी के रूप में, आपके पास पर्याप्त उपकरण/निगरानी है कि आप प्रदर्शन को मापने और उत्पादन में अपने अनुप्रयोग प्रोफ़ाइल कर सकते हैं होना चाहिए।

इसका यह भी अर्थ है कि आपके द्वारा कैश की जाने वाली प्रत्येक चीज़ में कैश हिट/मिस काउंटर होना चाहिए। कैश बर्बाद होने पर यह निर्धारित करने के लिए आप इसका उपयोग कर सकते हैं। यदि कैश में कम हिट दर है (< 9 0%, कहें), तो शायद यह सार्थक नहीं है।

यह व्यक्तिगत कैश उत्पादन में स्विच करने योग्य भी हो सकता है।

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