Google ऐप इंजन इंस्टेंस

Question

को जल्दी से बंद करना जारी रखता है इसलिए मैं कुछ समय के लिए ऐप इंजन का उपयोग कर रहा हूं। मुझे पता है कि यदि ऐप को थोड़ी देर के लिए किसी विज़िटर द्वारा नहीं मारा गया है तो इंस्टेंस बंद हो जाएगा, और साइट पर हिट करने वाले पहले विज़िटर को कुछ सेकंड देरी होगी जबकि एक नया इंस्टेंस फंस जाएगा।

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

मुझे क्या देखना चाहिए, या यह क्यों हो रहा है के बारे में कोई विचार है?

इसके अलावा, मैं पायथन 2.7, थ्रेडसेफ, पायथन_प्रोम्प्लेल्ड, वार्मअप इनबाउंड सर्विसेज, एनडीबी का उपयोग कर रहा हूं।

अद्यतन:

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

इसके अतिरिक्त, मैंने लंबित लेटेंसी को 1.5 के रूप में बदल दिया क्योंकि कोमा ने बताया, लेकिन यह मदद नहीं कर रहा है।

उदाहरणों का स्मृति उपयोग हमेशा 53 एमबी है, जो आश्चर्यजनक है जब पृष्ठों को बुलाया जा रहा है। मैं एफ 1 फ्रंटेंड इंस्टेंस क्लास का उपयोग कर रहा हूं और इसकी 128 की सीमा है, लेकिन किसी भी तरह से 53 एमबी ऐसा लगता है कि इसे क्या करना चाहिए। क्या यह स्वीकार्य आकार है जब यह पहली बार शुरू होता है?

अपडेट 2: मैंने पिछले 14 घंटों में डैशबोर्ड में देखा है कि अनुरोध/_ah/warmup ने 24 404 त्रुटियों के साथ जवाब दिया था। क्या यह संबंधित हो सकता है? वे 404 प्रतिक्रिया स्थिति के साथ क्यों प्रतिक्रिया दे रहे हैं?

मुख्य प्रश्न: यह लगातार नए उदाहरण क्यों शुरू कर रहा है (यहां तक ​​कि कोई ट्रैफ़िक नहीं है)? विशेष रूप से जहां पहले से मौजूद उदाहरण हैं, और वे इतनी जल्दी क्यों बंद हो जाते हैं?

Answer 1

मेरा समाधान लंबित लेटेंसी समय बढ़ाने के लिए था।

यदि कोई वेबपृष्ठ एक बार में 3 AJAX अनुरोधों को निकाल देता है, तो ऐपइंजिन अतिरिक्त अनुरोधों के लिए नए उदाहरण लॉन्च कर रहा था। न्यूनतम लंबित लेटेंसी समय को कॉन्फ़िगर करने के बाद - इसे 2.5 सेकेंड तक सेट करना, वही उदाहरण सभी तीन अनुरोधों को संसाधित कर रहा था और थ्रूपुट स्वीकार्य था।

मेरी परियोजना में अभी भी कम लोड/यातायात है ... इसलिए लंबित लेटेंसी को बढ़ाने के अलावा, मैंने पिंगडम पर एक खाता खोल दिया और इसे हर मिनट अपनी एपेंगिन परियोजना को पिंग करने के लिए कॉन्फ़िगर किया।

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

Answer 2

1 निष्क्रिय उदाहरण का अर्थ है कि ऐप-इंजन हमेशा आने वाले अगले उपयोगकर्ता के लिए एक अतिरिक्त उदाहरण को आग लगाएगा - यही कारण है कि आप उस सेटिंग के साथ एक अतिरिक्त उदाहरण निकाल रहे हैं।

यदि आप निष्क्रिय उदाहरण सेटिंग (या डिफ़ॉल्ट का उपयोग करें) को हटाते हैं और लंबित विलंबता को बढ़ाते हैं तो इसे अतिरिक्त उदाहरण को फायर करने से पहले "प्रतीक्षा करें" चाहिए।

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

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

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

Answer 3

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

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

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