2012-04-29 10 views
6

मैंने अपना कोड बहुत सुधार किया और अब सभी एपीआई वास्तव में तेजी से चलते हैं, मैंने भी memcache जोड़ा और मेरे पास एक शानदार हिट अनुपात है .. लेकिन कभी-कभी मुझे अर्थहीन देरी मिलती है।Google ऐप इंजन अजीब देरी

मैंने यहां सबसे महत्वपूर्ण ऐपस्टैट स्क्रीनशॉट संलग्न किए हैं: आरपीसी के 90 एमएमएस चलाने के लिए कुल मिलाकर 20 सेकंड से अधिक; यह कैसे संभव है? मुझे उन देरी की उत्पत्ति कहां मिलनी चाहिए?

मैं वास्तव में अटक गया हूं क्योंकि मुझे समझ में नहीं आता कि आरपीसी के बीच क्या हो रहा है और मुझे नहीं पता कि अधिक जानकारी प्राप्त करने के लिए मैं और क्या कर सकता हूं।

बस एक विचार: प्रत्येक HTTP कॉल को उसी GAE उदाहरण द्वारा संभाला जाता है, है ना? क्योंकि मेरे उदाहरणों ने गर्म करने के लिए बहुत समय लगाया .. लेकिन मुझे नहीं लगता कि यह

बीटीडब्लू: मैं जावा में कोडिंग कर रहा हूं।

appstats statistics

उत्तर

2

आमतौर पर एपस्टैट के बीच में "छेद" के लिए अनचाहे आपका कोड निष्पादित होता है।
Appstats प्रत्येक आरपीसी प्रविष्टि और निकास रिकॉर्ड करता है और जिन क्षेत्रों को वह रिकॉर्ड नहीं कर सकता वे आपके वास्तविक कोड चल रहे हैं।

क्या आपके पास उस समय के लिए लॉग है जिसमें एप्लिकेशन उन दो कॉलों के बीच था?

+0

आपको धन्यवाद .. हाँ, मैं log.fine (..) के साथ बहुत सी चीजें लॉग करता हूं, इसलिए मुझे केवल स्तर को सक्षम करना चाहिए और फिर फिर से देखो –

+0

जो मुझे विश्वास नहीं है 100% यह है कि एक HTTP कॉल को विभिन्न उदाहरणों से संभाला जाता है। क्या यह संभव है? क्योंकि यह एक और समस्या हो सकती है, क्योंकि एक नया उदाहरण गर्म करने में काफी समय लगा! –

+0

@MicheleOrsi आप हैंडलर निष्पादन के दौरान उदाहरण कूद नहीं सकते –

2

विशाल, 'अस्पष्टीकृत' विलंबता लगभग हमेशा संसाधनों को gobbling अनुरोध वार्मअप है। यह देखने के लिए अपने एपेंजिन लॉग का निरीक्षण करें कि गर्मियों पर कितने api_ms और cpu_ms का उपयोग किया जा रहा है।

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

वार्मअप अनुरोध के साथ मदद करने के लिए, सुनिश्चित करें कि आपके ऐप्लिकेशन इंजन-web.xml है:

<warmup-requests-enabled>true</warmup-requests-enabled> 

इस ऐप्लिकेशन इंजन डिस्पैचर कारण होगा preemptively नया दृष्टांत आग जब वर्तमान लोगों अतिभारित किया जा रहा है {अर्थात एक अनुरोध नए अनुरोध पर जाने से पहले लोड हो जाता है}।

<servlet> 
    <servlet-name>my-servlet</servlet-name> 
    <servlet-class>com.company.MyServlet</servlet-class> 
    <load-on-startup>1</load-on-startup> 
</servlet> 

लोड-ऑन-स्टार्टअप केवल सुनिश्चित करता है कि आपके उच्च प्राथमिकता सर्वलेट्स हमेशा तैयार हैं:

तो, प्रभावित धीमी सर्वलेट्स में, सुनिश्चित करें कि आप अपने web.xml में लोड-ऑन-स्टार्टअप डाल कर जैसे ही गर्मजोशी का अनुरोध खत्म हो जाता है।

+0

धन्यवाद, लेकिन मैं पहले से ही आपके सभी सुझाव कर रहा हूं: हॉटअप-अनुरोध-सक्षम, लोड-ऑन-स्टार्टअप और मेरी लंबित लेटेंसी 11.5 पर सेट है - स्वचालित .. –

+0

क्या आप अपना परीक्षण दोबारा चला सकते हैं और देख सकते हैं कि कैसे कई उदाहरण निकाल दिए गए हैं? जांचें कि क्या आप लॉग में लोडिंग अनुरोध प्राप्त कर रहे हैं, और उनमें से कितने हैं। साथ ही, क्या आप एक ही समय में अपने सभी आरपीसी फायर कर रहे हैं? यदि आपके ब्राउज़र में दो से अधिक कनेक्शन खुले हैं, तो यह लंबित लोगों पर अवरुद्ध होगा, जो आपके servlets को अवरुद्ध कर सकता है। फ़ायरबग में अनुरोधों को देखें और यह देखने के लिए कि क्या आप यह चुन सकते हैं कि कौन से अनुरोध आपको 9 0 एमएमएस अनुरोधों पर 20s तक पहुंचा रहे हैं। – Ajax

+0

इसके अलावा, 11.5 के लंबित विलंबता का अर्थ है कि प्रत्येक कनेक्शन में 10 से अधिक विलंबता हो सकती है। अपने लोडिंग अनुरोधों को मापें। यदि एक लोड अनुरोध 15 है, और अधिकतम लंबित विलंबता 11 है, तो आपका पहला लोडिंग अनुरोध 10s का इंतजार करेगा, फिर एक नया उदाहरण आग लगाने के लिए 15 और ले लें।आप लंबित विलंबता को चालू करना चाहते हैं और लोडिंग अनुरोधों पर बुलेट को काट सकते हैं। – Ajax