नेटवर्क कैश के लिए MemCache और MongoDb की तुलना करना

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

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

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

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

हम लेख के मुख्य भाग पर आगे बढ़ते हैं, अर्थात् हमारे डीब्रीफिंग के लिए।
कैशिंग प्रदर्शन की तुलना करने के लिए, निम्नलिखित कैशिंग टूल का चयन किया गया था: APC , MemCache , RamFS , TmpFS , XCache , साथ ही साथ (असाधारण पसंद), बल्कि तेजी से DBMS MongoDB ।

मुझे लगता है कि हमें इन सभी कार्यक्रमों और एक्सटेंशनों को स्थापित करने के साथ शुरुआत करने की आवश्यकता है, और हमें किन कठिनाइयों का सामना करना पड़ा।
सभी प्रयोगों को 2Gb मेमोरी और स्थापित PHP [5.3.6] के साथ एक CentOS सिस्टम पर किया गया था, और निष्पक्षता के लिए, हमने एक भी पैकेज कॉन्फ़िगर नहीं किया, सब कुछ "बॉक्स से बाहर" लिया गया।

APC [3.1.9] स्थापित करना:
सब कुछ सरल और आसान है। हम pecl के माध्यम से पैकेज को स्थापित करते हैं और यह एपीसी काम करता है।

Memcache स्थापना [2.2.6] :
साथ ही काफी सरल भी। हम पैकेज को pecl के माध्यम से भी स्थापित करते हैं, और फिर अलग से मेमेचे प्रोग्राम को स्वयं स्थापित करते हैं, क्योंकि यह एक विस्तार नहीं है, लेकिन एक तृतीय-पक्ष कार्यक्रम है जिसे अलग से स्थापित किया जाना चाहिए, लेकिन यह मुश्किल नहीं है। स्थापना के बाद, सब कुछ आश्चर्यजनक रूप से काम किया।

रामएफएस स्थापित करें:
यह स्थापना से भी अधिक सृजन है। सब कुछ बहुत सरल भी है: mount -t ramfs -o size=1024m ramfs /tmp/ramfs , यहां हम 1 जीबी मेमोरी आवंटित करते हैं और इसे /tmp/ramfs में फाइल सिस्टम के रूप में माउंट करते हैं।

TmpFS स्थापित करें:
साथ ही, जैसा कि पिछले मामले में है, यह एक निर्माण है, स्थापना नहीं। यह mount -t tmpfs -o size=1024m tmpfs /tmp/tmpfs कमांड mount -t tmpfs -o size=1024m tmpfs /tmp/tmpfs , जो यह दर्शाता है कि हम 1Gb मेमोरी भी आवंटित करते हैं और इसे /tmp/tmpfs में फाइल सिस्टम के रूप में माउंट करते हैं।

नोट:

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

XCache स्थापित करना [1.3.1] :
और यहाँ दिलचस्प बात शुरू होती है जिसका हम सामना कर रहे हैं। इस पैकेज को स्थापित करना इस तथ्य के कारण काफी विवेकपूर्ण था कि सिस्टम पर PHP 5.2 भी स्थापित किया गया था (और यह वर्तमान में सिस्टम में मुख्य है), Xache की निर्भरता की एक बड़ी सूची है, और इस पैकेज को स्थापित करने की आवश्यकता के कारण फिसलने की समस्या थी उसे पुस्तकालयों की जरूरत है। लेकिन इसके साथ भी, इस विस्तार के साथ समस्याएं समाप्त नहीं हुईं, क्योंकि स्थापना के बाद (और यह सामान्य लग रहा था) इस विस्तार के सही संचालन को सत्यापित करने के लिए एक परीक्षण के साथ एक स्क्रिप्ट के लॉन्च के दौरान, नई समस्याएं पैदा हुईं जब स्मृति को एक चर लिखने की कोशिश कर रहा था। एक त्रुटि हुई:

Warning: xcache_set(): xcache.var_size is either 0 or too small to enable var data caching in /usr/local/php5.3/xcache.php on line 6

और उसके पीछे निम्नलिखित था:

Warning: xcache_get(): xcache.var_size is either 0 or too small to enable var data caching in /usr/local/php5.3/xcache.php on line 10

इस त्रुटि के सीधे हाथों से लड़ने के 2 दिन बाद, एक कीबोर्ड और एक टैम्बोरिन, परिणाम शून्य था। ऐसी अटकलें थीं कि * .so को गलत तरीके से इकट्ठा किया गया था, हालांकि, हमारे एकत्रित * को बदलने के लिए। इंटरनेट से डाउनलोड किए गए एक ही संस्करण के साथ कुछ भी नहीं हुआ। अंकल Google हरकत में आ गया, ठीक वही StackOverflow समस्या पाई गई। हालांकि, उन्हें इस समस्या का हल नहीं मिला, इसलिए उन्हें XCache के बिना आगे के परीक्षण करने के लिए मजबूर किया गया। बहुत निराशा नहीं हुई, क्योंकि पिछले परीक्षणों से पता चला था कि APC और XCache के बीच अंतर लगभग नगण्य है, लेकिन XCache के साथ बहुत अधिक समस्याएं हैं।

MongoDB स्थापित करें [1.8.1] :
मैंगो इंस्टॉलेशन काफी सरल है और मैं इसकी प्रक्रिया का वर्णन नहीं करूंगा, हालांकि, मैं आपको उस कॉन्फ़िगरेशन के साथ लॉन्च करूंगा जिसकी हमें आवश्यकता है:
/usr/local/mongodb/bin/mongod --dbpath /usr/local/mongodb/data --profile=0 --maxConns=1500 --fork --logpath /dev/null --noauth --diaglog=1 --syncdelay=0
मुख्य पैरामीटर जो हमें --syncdelay=0 है वह अंतिम " --syncdelay=0 " है, जो HDD पर डेटा के साथ मेमोरी में डेटा के सिंक्रनाइज़ेशन के समय को इंगित करता है। 0 के निर्दिष्ट मूल्य का मतलब है कि हम स्पष्ट रूप से एचडीडी के साथ मैंगो सिंक्रोनाइजेशन पर रोक लगाते हैं, यह सुविधा डीबीएमएस के रचनाकारों द्वारा वर्णित है, लेकिन यह इस तथ्य के कारण अनुशंसित नहीं है कि किसी भी पावर आउटेज या अन्य सिस्टम विफलता के साथ जो मैंगो डेमन को प्रभावित कर सकती है, आपका सभी डेटा खो जाएगा। । हम इस जोखिम से काफी संतुष्ट हैं, क्योंकि हम इस DBMS को कैशिंग तंत्र के रूप में उपयोग करने का प्रयास करना चाहते हैं।

ऐसा लगता है कि सब कुछ स्थापित है और "कॉन्फ़िगर" है, अब हम सीधे परीक्षणों के लिए स्वयं आगे बढ़ते हैं।

अधिक ईमानदारी के लिए, हम 4 संग्रहीत डेटा वॉल्यूम के साथ परीक्षण करेंगे: 4Kb, 72Kb, 144Kb, 2.12Mb ।

ग्राफ़ पर प्राप्त आंकड़ों पर विचार करें:

4KB:

जैसा कि आप 1 चार्ट (4Kb डेटा रिकॉर्ड करने के लिए समयरेखा) पर देख सकते हैं - मेमेचे ने सबसे खराब परिणाम दिखाया, इसके बाद रामफ्स और टीएमपीएफ, फिर मोंगो और एपीसी।


दूसरे ग्राफ पर (4Kb डेटा पढ़ने के लिए समयरेखा), Mongo पीछे वाले को स्पष्ट रूप से देखता है, जबकि MemCache लगभग RamFs और TmpFs के लिए तुलनीय है, जो लगभग संयोग से, इस ग्राफ पर उनके बीच की विसंगति लगभग अदृश्य है।

72kb:

3rd चार्ट (72Kb डेटा रिकॉर्ड करने के लिए समयरेखा) से, MemCache अनुचित तरीके से व्यवहार करता है, और Mongo काफी अनुमानित है। यह बहुत आश्चर्य की बात है कि एपीसी, रैमएफ और टीएमपीएफ लगभग मेल खाते हैं।


और यहां 4 वें चार्ट पर रीडिंग प्रदर्शित की गई है (72Kb डेटा पढ़ने के लिए समयरेखा): मानगो ने अपनी जमीन खो दी और एपीसी से पहले अपने प्रतिद्वंद्वी मेकचे को आगे बढ़ने दिया।

144kb:

5 वें ग्राफ (144Kb डेटा रिकॉर्डिंग टाइमलाइन) से शुरू होकर हम लगभग सभी प्रणालियों के पहले से ही अजीब व्यवहार को देखते हैं - मेमकेच बहुत अस्थिर रूप से व्यवहार करता है और कभी-कभी पुनरावृत्तियों की एक छोटी संख्या में समय एक बड़े पैमाने पर की तुलना में अधिक होता है, और इससे भी अधिक आश्चर्यजनक यह है कि यह करीब है 500 पुनरावृत्तियों के लिए एपीसी से आगे निकलना शुरू होता है! RamFs और TmpFs गति में आश्चर्यजनक रूप से उच्च बार रखते हैं।


6 वें ग्राफ पर (144Kb डेटा पढ़ने के लिए समय) Mongo हर किसी के लिए खो देता है, और APC सबसे तेज है।

2.12Mb:

7 वें ग्राफ पर (2.12Mb डेटा रिकॉर्डिंग के लिए समयरेखा), Mongo बहुत स्थिर निकला, हालांकि, अंतिम पुनरावृत्ति 500 ​​बार उसे अनिश्चित बना दिया, लेकिन वह काठी में रहा। बेशक, अश्लील नेता एपीसी है, लेकिन मेमकेच, टीएमपीएफ और रामएफ के साथ कुछ दिलचस्प हो रहा है, जिसे नीचे वर्णित किया जाएगा।


आखिरी ग्राफ (2.12Mb डेटा की टाइमलाइन पढ़ना) भी एक बहुत ही अद्भुत तस्वीर है: TmpFs सबसे धीमी और रामएफ सबसे तेज निकली। एक और आश्चर्यजनक बात यह है कि मानगो एपीसी से आगे निकल गया!

यदि आप पिछले 2 ग्राफ़ के अंतिम पुनरावृत्तियों को देखते हैं, जिसमें फ़ाइलों को 2.12Mb 500 बार कैश किया गया था, तो आप एक दिलचस्प बात देख सकते हैं कि 500 ​​(पुनरावृत्तियों की संख्या) * 2.12 (एक फ़ाइल का आकार) = 1% 060Mb, जो हमें बताता है कि रामएफएस और TmpFS में हम अधिकतम मात्रा से आगे निकल गए! इसलिए, संख्या काफी दिलचस्प और अप्रत्याशित हैं।
वास्तव में, सब कुछ केवल अनुमानित रूप से निकला: जब ऊपरी सीमा (और हमारे पास 1024 एमबीबी है), रामएफएस केवल डेटा लिखना बंद कर देता है और लिखने के आदेशों को अनदेखा करता है। इस डेटा को पढ़ते समय, पढ़ना शारीरिक रूप से नहीं होता है, लेकिन बस एक खाली स्ट्रिंग देता है (जब PHP में प्रसंस्करण होता है, तो स्ट्रिंग खाली नहीं होती है, लेकिन इसे अशक्त माना जाता है), जबकि TmpFS बिल्कुल विपरीत व्यवहार करता है - यह हमारे सभी डेटा को लिखता है, उनके लिए पूर्व-आवंटन करता है पुराने डेटा को स्वैप करने के लिए जगह देकर। यह इस तथ्य की व्याख्या करता है कि इस तरह के संस्करणों और समान संख्या में पुनरावृत्तियों के साथ, रामएफएस को रिकॉर्ड को संसाधित करने में काफी कम समय लगता है और गैर-मौजूद डेटा को पढ़ने के लिए कम समय भी लगता है, जबकि इसके विपरीत, TmpFS इस समय डिस्क संचालन करने की आवश्यकता के कारण बहुत बढ़ जाता है।
जैसा कि मैंने ऊपर बताया, सभी फंडों को "बॉक्स से बाहर" ले लिया गया था, इन उपकरणों को कॉन्फ़िगर नहीं किया गया था, इसलिए मेम्चे का समय 0 है, क्योंकि आकार में 2.12Mb के एक रिकॉर्ड की दर्ज की गई मात्रा, केवल मेमचे में एक संग्रहीत रिकॉर्ड की अधिकतम मात्रा से अधिक है। 2.12Mb से बड़े डेटा को स्टोर करने में सक्षम होने के लिए मेमकेच के लिए, स्वयं मेकचे को फिर से बनाना आवश्यक है, लेकिन फिर उसके अनुसार सब कुछ कॉन्फ़िगर करना आवश्यक होगा, लेकिन विभिन्न उत्पादों को उसी तरह से कॉन्फ़िगर करना लगभग असंभव होगा, इसलिए मैंने खुद को इस बारीकियों को छोड़ने की अनुमति दी। जैसा अभी है। शायद यह सच नहीं है, लेकिन हम समान परिस्थितियों में इन सभी साधनों के व्यवहार में अधिक रुचि रखते थे - "बॉक्स से बाहर"।

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

आप सिस्टम के बारे में इस तरह से भी सोच सकते हैं कि मल्टी-लेवल कैश है: फ़र्स्ट-लेवल कैश (नेटवर्क कैश) मेमेचे या मोंगो, और सेकंड-लेवल कैश APC या XCache (लेकिन तुलना अभी भी आवश्यक है)।

निकट भविष्य में, एक अधिक गहराई से विश्लेषण और MemCache और Mongo की तुलना करने की योजना बनाई गई है - न केवल खर्च किए गए समय की तुलना में, बल्कि प्रोसेसर और सर्वर पर लोड को मापने के साथ खर्च की गई मेमोरी की भी।

अंत में, मैं यह इंगित करना चाहता हूं कि परीक्षण बार-बार चलाए गए थे और टेबलों में दिखाए गए डेटा परीक्षणों के 10-20 पुनरावृत्तियों का औसत है।
मैं बड़ी मात्रा के कारण सारणीबद्ध परीक्षण डेटा नहीं दूंगा।