Google ऐप इंजन कैशिंग

जैसा कि आप पिछले लेख से पहले से ही जानते हैं, ऐप इंजन में जानकारी संग्रहीत करने के कई तरीके हैं। लेकिन उनमें से कई बहुत विशिष्ट हैं, और केवल तीन व्यापक उपयोग के लिए उपयुक्त हैं: उदाहरण के लिए मेमोरी, मेम्चे और डेटास्टोर।

कटौती के तहत, आपको संख्याओं और चित्रों में एक सारांश, कैशिंग पर संक्षिप्त सिफारिशें और एक साधारण कैचर के स्रोत कोड और एक परीक्षण एप्लिकेशन मिलेगा।

परीक्षण पद्धति।

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

डाटा।

एक यादृच्छिक जनरेटर के परिणामों का उपयोग किया जाता है - प्रत्येक उपधारा में, पहले 60 केबी के बारे में पाठ के साथ एक रिकॉर्ड के लिए परिणाम होते हैं, फिर 1000 छोटे रिकॉर्ड (औसत टिप्पणी के अनुरूप) की सूची के लिए।

डेटास्टोर।

आइए, सबसे विश्वसनीय और धीमे भंडारण के साथ, शुरू करें। हमें 60Kb में डेटासोर से get_by_key_name () विधि का उपयोग करके एक रिकॉर्ड मिलता है:


यह अच्छा लग रहा है - रनटाइम और उपभोग किए गए संसाधनों के संदर्भ में, अब चलो एक हजार "टिप्पणियों" का एक नमूना प्राप्त करने की कोशिश करते हैं:


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

नोट: 10 सेकंड api_cpu को सभी () द्वारा प्राप्त किया गया था। 1000 रिकॉर्ड्स के समूह पर Fetch (1000) विधि, GqlQuery को निष्पादित करते समय, और भी अधिक रिकॉर्ड से चयन करने के लिए अधिक संसाधनों का उपभोग किया जाएगा। जब मैंने देखा कि सबसे बड़ा 561,000 एपीआई_कैप_एमएस था जब एचआरडीएस (उच्च प्रतिकृति डेटास्टोर) में 1000 रिकॉर्ड जोड़े गए थे। इसलिए ऐप इंजन में बड़े चयन के साथ आपको बेहद सावधानी से काम करने की आवश्यकता है।

मेम्कैश।

सबसे सार्वभौमिक उपकरण मेमेकैच है, इसमें पहली बात यह है कि डेटास्टेट को क्वेरी करने के परिणामों को संग्रहीत करने की सिफारिश की जाती है।



रिकॉर्डिंग लगभग 2 गुना तेज है और 2 गुना कम प्रोसेसर समय की आवश्यकता है। सच है, पूर्ण शब्दों में, 10ms की बचत गंभीर नहीं लगती है। अब देखते हैं कि मेकैच सूची को कैसे पचाता है:


यहां, बचत बहुत अधिक है: 1.5 गुना तेज और 15 गुना सस्ता।

मेम्चे + प्रोटोबुफ़।

Memcache स्वतंत्र और लगभग प्रतिबंधों के बिना है, लेकिन अभी भी रबर नहीं है - प्रोटोकॉल बफर में db.Model वर्ग की वस्तुओं को क्रम में रखकर डेटा के आकार को कम करने की कोशिश करें (जैसा कि इस लेख में अनुशंसित है)। यह डेटा को मेमकेच में लंबे समय तक संग्रहीत करने की अनुमति देगा, लेकिन क्या एप्लिकेशन बेहतर काम करेगा?



यदि पहले मामले में अंतर लगभग दिखाई नहीं दे रहा है, तो दूसरे में निष्पादन समय और खपत संसाधनों में वृद्धि स्पष्ट रूप से 25-25% तक दिखाई देती है।

मेकचे + प्रोटोबुफ़ + ज़्लिब।

चूंकि हम आकार को कम कर रहे हैं, इसलिए हमें संग्रह करने की कोशिश करने की आवश्यकता है, इसके लिए हम zlib.compress का उपयोग करते हुए क्रमबद्ध लाइनों को संकुचित करेंगे।



Memcache.Get रनटाइम इस तथ्य के कारण 1ms कम हो गया कि संपीड़ित पाठ बहुत तेजी से प्रसारित होता है। हालांकि, डेटा को अनपैक करते समय सभी संचित लाभ खो जाते हैं।


बड़ी संख्या में छोटे रिकॉर्ड में ऐसा कोई लाभ नहीं है, केवल समय और संसाधनों में लगभग 5% की वृद्धि हुई है।

स्थानीय स्मृति।

इसलिए हमें उत्पादकता बढ़ाने के चरम साधन मिल गए - उदाहरण स्मृति। कई कमियों के अलावा (प्रत्येक उदाहरण की अपनी स्मृति है, यह स्मृति केवल 50 एमबी है, उदाहरण 9000 अनुरोधों की अधिकतम आयु तक पहुंचने के लिए अत्यंत दुर्लभ हैं), इसका मुख्य लाभ है - गति।

हमेशा की तरह, एक प्रविष्टि के लिए, बचत महत्वपूर्ण नहीं है, एक सूची के साथ, यह पूरी तरह से अलग मामला है:

रनटाइम 100 गुना कम हो गया है, और कंप्यूटिंग संसाधनों की अब आवश्यकता नहीं है - एक पंक्ति में सब कुछ कैश करने के लिए इंस्टेंस मेमोरी का उपयोग करने के लिए एक अच्छा तर्क।

लेकिन कमियों के बारे में मत भूलना:

1. प्रत्येक उदाहरण की अपनी स्मृति होती है और तदनुसार, उसका कैश।
2. केवल 50MB मेमोरी।

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

स्थानीय मेमोरी + प्रोटोबॉफ़।

एक रिकॉर्ड के लिए, समय में उतार-चढ़ाव लगभग त्रुटि के भीतर है, हालांकि, सूची पर एक गंभीर लक्षण दिखाई देता है: उदाहरण के लिए समय और संसाधन स्मृति और संयोग से व्यावहारिक रूप से मेल खाते हैं। इस तरह के एक सरल तरीके से, संपीड़न एक प्रदर्शन लाभ को नष्ट कर सकता है।

स्थानीय मेमोरी + प्रोटोबॉफ़ + ज़्लिब।

और आदेश के लिए, zlib का उपयोग करके इंस्टेंस मेमोरी से डेटा प्राप्त करना:



कोई चमत्कार नहीं हुआ - सूची प्राप्त करने में अभी भी बहुत समय लगता है और बहुत सारे संसाधनों की खपत होती है।

निष्कर्ष।

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

आवेदन कोड।

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