एक नई मूल्य सूची के लिए अनुकूलन

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

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

परिचय।

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

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

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

हम पुरानी और नई रिपोर्टों का अध्ययन करते हैं।

दैनिक उपयोग की रिपोर्ट्स नियंत्रण कक्ष में स्थित बिलिंग इतिहास पृष्ठ पर _https://appengine.google.com/billing/history?&app_id=$APP_ID । एक रिपोर्ट के बगल में [+] आइकन पर क्लिक करने से एक दिन के विवरण का विस्तार होगा, जहां आप नए और पुराने संसाधनों को देख सकते हैं। आपके आवेदन के लिए उपयोग रिपोर्ट का पूर्वावलोकन कुछ इस तरह दिखता है:

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

उदाहरणों का उपयोग प्रबंधित करें।

नए खाते की पहली दो पंक्तियाँ एप्लिकेशन इंस्टेंसेस के उपयोग की चिंता करती हैं। आप हमारे प्रलेखन में उदाहरणों के बारे में पढ़ सकते हैं। आप कंट्रोल पैनल में एप्लिकेशन द्वारा उपयोग किए जाने वाले इंस्टेंस की संख्या _https://appengine.google.com/instances?&app_id=$APP_ID या ड्रॉप-डाउन सूची में इंस्टेंस चार्ट का चयन करके _https://appengine.google.com/dashboard?&app_id=$APP_ID ।

शेड्यूलर ऐप इंजन।

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

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

प्रयुक्त उदाहरणों की संख्या को कम करने के लिए रणनीतियाँ।

विलंबता को कम करना।

आपके एप्लिकेशन की देरी से एप्लिकेशन को सेवा देने के लिए आवश्यक इंस्टेंस की संख्या पर बड़ा प्रभाव पड़ता है। इसलिए, देरी को कम करना आवश्यक उदाहरणों की संख्या को बहुत प्रभावित कर सकता है। विलंबता को कम करने के लिए चरणों की एक सूची इस प्रकार है:

• कैश अक्सर साझा किए गए डेटा का अधिक उपयोग करता है। दूसरे शब्दों में: Memcache का उपयोग करें। यदि आप एप्लिकेशन के लिए कैश-कंट्रोल हेडर भी सेट करते हैं, तो आप सर्वर और ब्राउज़रों की कैशिंग दक्षता को बढ़ा सकते हैं। यहां तक ​​कि कुछ सेकंड के लिए कैशिंग करने से एप्लिकेशन की दक्षता बढ़ सकती है। पायथन एप्लिकेशन को रनटाइम कैशिंग का भी उपयोग करना चाहिए।
• Memcache का अधिक कुशलता से उपयोग करें। एकल की एक श्रृंखला के बजाय बैच कॉल का उपयोग करें।
• गैर-क्वेरी गतिविधियों के लिए कार्य का उपयोग करें। यदि आपका एप्लिकेशन उन कार्यों को करता है जो अनुरोध करने वाले उपयोगकर्ता के बाहर किए जा सकते हैं, तो उसे कार्यों पर भेजें। अनुरोध को पूरा करने के लिए निष्पादन की प्रतीक्षा करने के बजाय टास्क कतार में इन कार्यों को भेजना उपयोगकर्ता को ध्यान देने योग्य देरी को काफी कम कर देगा। एक कार्य कतार निष्पादन की गति पर बहुत अधिक नियंत्रण प्रदान कर सकती है और लोड को समान रूप से वितरित करने में मदद करती है।
• अपने डेटा वेयरहाउस का अधिक कुशलता से उपयोग करें। हम नीचे दिए गए विवरण में तल्लीन करेंगे।
• समानांतर में URL फ़ेच अनुरोध भेजें।
  • अतुल्यकालिक एपीआई कॉल ( जावा , पायथन ) का उपयोग करें
  • संकुल में URL फ़ेच को मिलाएं (जिसे आप उपयोगकर्ता के अनुरोध के दौरान एक समय में संसाधित कर सकते हैं) और उन्हें अतुल्यकालिक URL फ़ेच के समानांतर एक ऑफ़लाइन कार्य में संसाधित करें।
• जावा में HTTP सत्रों को असिंक्रोनस रूप से रिकॉर्ड करें। HTTP सत्र आपको एप्लिकेशन डेटा को असेंबली में डेटा सत्र में लिखने के लिए कॉन्फ़िगर करता है <async-session-persistence enabled="true"/> appync-web -xml फ़ाइल में <async-session-persistence enabled="true"/> जोड़कर। सत्र डेटा को हमेशा सिंक्रोनाइज़ करने के लिए लिखा जाता है, और यदि अनुरोध डेटा प्राप्त करने की कोशिश करता है, जो मेकचे में नहीं है, तो अनुरोध डेटास्टर को भेजा जाता है, जिसमें अभी तक नवीनतम अपडेट नहीं हो सकता है। इसका मतलब है कि इस बात का बहुत कम जोखिम है कि एप्लिकेशन को समाप्त सत्र डेटा प्राप्त होगा, लेकिन अधिकांश अनुप्रयोगों के लिए, गति इस जोखिम को दूर करती है।

शेड्यूलर को मैन्युअल रूप से समायोजित करें।

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

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

जावा में समवर्ती अनुरोध सक्षम करें।

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

नोट : पायथन के लिए मल्टीथ्रेडिंग कार्य योजना में उपलब्ध पायथन 2.7 के लॉन्च तक उपलब्ध नहीं होगा। पाइथन 2.7 में, बहु-थ्रेडेड इंस्टेंसेस अधिक अनुरोधों को संभाल सकते हैं और ऐसे घंटों कोटा का उपभोग नहीं करना चाहिए, जब अवरुद्ध प्रतिक्रियाओं का इंतजार करते समय निष्क्रिय हों। चूंकि पायथन वर्तमान में एक समय में एक से अधिक अनुरोधों की सेवा देने की क्षमता का समर्थन नहीं करता है, और सभी डेवलपर्स को एक साथ अनुरोधों के अनुकूल होने की अनुमति देने के लिए, हम 20 नवंबर, 2011 तक फ्रंटएंड के उदाहरणों के काम के घंटों पर 50% की छूट प्रदान करेंगे। पायथन 2.7 अब बंद है परीक्षण।

अनुप्रयोग संग्रहण प्रबंधन।

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

• आपके एप्लिकेशन के लिए कौन से इंडेक्स सेट किए गए हैं, यह जांचने के लिए गेट इंडेक्स फ़ंक्शन ( जावा , पायथन ) का उपयोग करें। किसी भी इंडेक्स को हटाना जो एप्लिकेशन के लिए आवश्यक नहीं है, डेटा स्टोरेज पर बचाएगा और ऑब्जेक्ट रिकॉर्ड करने की लागत को कम करेगा। इसके अलावा, आप कंट्रोल पैनल में वर्किंग एप्लिकेशन इंडेक्स _https://appengine.google.com/datastore/indexes?&app_id=$APP_ID ।
• डेटा मॉडल डिज़ाइन करते समय, यह देखने के लिए जांचें कि क्या आप कुल अनुक्रमणिका की संख्या को कम करने के लिए क्वेरी लिख सकते हैं। ऐप इंजन कैसे इंडेक्स बनाता है, इसकी अधिक जानकारी के लिए हमारी क्वेरी और इंडेक्स डॉक्यूमेंटेशन पढ़ें।

डेटास्टोर का उपयोग करके प्रबंधित करें।

नए मॉडल में, हम डेटास्टोर (वर्तमान में उपयोग किए गए सीपीयू संसाधनों के बजाय) में किए गए संचालन की संख्या को ध्यान में रखेंगे। कुछ रणनीतियाँ जो डेटास्टर संसाधनों की खपत में कमी ला सकती हैं, साथ ही डेटास्टर अनुरोधों की विलंबता को कम करने के लिए:

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

यातायात प्रबंधन।

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

आने वाले ट्रैफ़िक को नियंत्रित करना अधिक कठिन है, क्योंकि यह उपयोगकर्ताओं द्वारा एप्लिकेशन को भेजे गए डेटा की मात्रा है। हालाँकि, यह DoS सुरक्षा सेवा ( Java , Python ) का उल्लेख करने का एक अच्छा अवसर है, जो आपको अवांछित ट्रैफ़िक से यातायात को अवरुद्ध करने की अनुमति देगा।

अन्य संसाधनों का प्रबंधन।

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