कभी-कभी क्रोम

Question

में लंबे समय तक रुकने का अनुरोध अजाक्स अनुरोध कभी-कभी क्रोम में लंबे समय तक रुक गया।

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

और chrome://net-internals/#events भीतर पेज मैं सबसे पाया (घटनाओं के लिए लॉग इन करें समाप्त करने के लिए सिर कृपया):

Chrome डेवलपर टूल की सहायता से समय अनुरोध के बाद स्क्रीन पर कब्जा के रूप में 42.62s के लिए ठप से पता चलता चलता समय दो घटनाओं से खर्च किया जाता है:

• + HTTP_TRANSACTION_READ_HEADERS [dt = 21,301]
• + HTTP_TRANSACTION_READ_HEADERS [dt = 21,304]

दोनों ERR_CONNECTION_RESET प्राप्त करते हैं।

मुझे लगता है कि त्रुटि कारण है कि अनुरोध इतने लंबे समय के लिए ठप है।

कोई भी त्रुटियों की व्याख्या कर सकता है?

अनुरोध के लिए घटनाएं लॉग इन हैं, मैं पूरी घटनाओं को निर्यात करता हूं क्योंकि आप here से प्राप्त कर सकते हैं, फिर क्रोम chrome://net-internals/#events पृष्ठ के भीतर पुनर्स्थापित करें। ध्यान दें अनुरोध यूआरएल सार्वजनिक नेटवर्क से आंतरिक तो शायद नहीं कर सकते पहुंच है:

193486: URL_REQUEST 
 
http://qa.tieba.baidu.com/release/getReleaseHistory?projectId=fum1.0.593 
 
Start Time: 2015-01-02 17:51:05.323 
 

 
t= 1 [st= 0] +REQUEST_ALIVE [dt=42741] 
 
t= 1 [st= 0] URL_REQUEST_DELEGATE [dt=0] 
 
t= 1 [st= 0] +URL_REQUEST_START_JOB [dt=42740] 
 
         --> load_flags = 339804160 (BYPASS_DATA_REDUCTION_PROXY | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VERIFY_EV_CERT) 
 
         --> method = "GET" 
 
         --> priority = "LOW" 
 
         --> url = "http://qa.tieba.baidu.com/release/getReleaseHistory?projectId=fum1.0.593" 
 
t= 2 [st= 1]  URL_REQUEST_DELEGATE [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_GET_BACKEND [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_OPEN_ENTRY [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_ADD_TO_ENTRY [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_READ_INFO [dt=0] 
 
t= 2 [st= 1]  URL_REQUEST_DELEGATE [dt=0] 
 
t= 2 [st= 1]  +HTTP_STREAM_REQUEST [dt=2] 
 
t= 4 [st= 3]  HTTP_STREAM_REQUEST_BOUND_TO_JOB 
 
          --> source_dependency = 193488 (HTTP_STREAM_JOB) 
 
t= 4 [st= 3]  -HTTP_STREAM_REQUEST 
 
t= 4 [st= 3]  +HTTP_TRANSACTION_SEND_REQUEST [dt=0] 
 
t= 4 [st= 3]  HTTP_TRANSACTION_SEND_REQUEST_HEADERS 
 
          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1 
 
           Host: qa.tieba.baidu.com 
 
           Connection: keep-alive 
 
           Accept: application/json, text/plain, */* 
 
           User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
 
           Referer: http://qa.tieba.baidu.com/project/ 
 
           Accept-Encoding: gzip, deflate, sdch 
 
           Accept-Language: en-US,en;q=0.8 
 
           Cookie: [268 bytes were stripped] 
 
t= 4 [st= 3]  -HTTP_TRANSACTION_SEND_REQUEST 
 
t= 4 [st= 3]  +HTTP_TRANSACTION_READ_HEADERS [dt=21301] 
 
t= 4 [st= 3]  HTTP_STREAM_PARSER_READ_HEADERS [dt=21301] 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=21305 [st=21304]  HTTP_TRANSACTION_RESTART_AFTER_ERROR 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=21305 [st=21304]  -HTTP_TRANSACTION_READ_HEADERS 
 
t=21305 [st=21304]  +HTTP_STREAM_REQUEST [dt=3] 
 
t=21307 [st=21306]  HTTP_STREAM_REQUEST_BOUND_TO_JOB 
 
          --> source_dependency = 193494 (HTTP_STREAM_JOB) 
 
t=21308 [st=21307]  -HTTP_STREAM_REQUEST 
 
t=21308 [st=21307]  +HTTP_TRANSACTION_SEND_REQUEST [dt=3] 
 
t=21308 [st=21307]  HTTP_TRANSACTION_SEND_REQUEST_HEADERS 
 
          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1 
 
           Host: qa.tieba.baidu.com 
 
           Connection: keep-alive 
 
           Accept: application/json, text/plain, */* 
 
           User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
 
           Referer: http://qa.tieba.baidu.com/project/ 
 
           Accept-Encoding: gzip, deflate, sdch 
 
           Accept-Language: en-US,en;q=0.8 
 
           Cookie: [268 bytes were stripped] 
 
t=21311 [st=21310]  -HTTP_TRANSACTION_SEND_REQUEST 
 
t=21311 [st=21310]  +HTTP_TRANSACTION_READ_HEADERS [dt=21304] 
 
t=21311 [st=21310]  HTTP_STREAM_PARSER_READ_HEADERS [dt=21304] 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=42615 [st=42614]  HTTP_TRANSACTION_RESTART_AFTER_ERROR 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=42615 [st=42614]  -HTTP_TRANSACTION_READ_HEADERS 
 
t=42615 [st=42614]  +HTTP_STREAM_REQUEST [dt=12] 
 
t=42627 [st=42626]  HTTP_STREAM_REQUEST_BOUND_TO_JOB 
 
          --> source_dependency = 193498 (HTTP_STREAM_JOB) 
 
t=42627 [st=42626]  -HTTP_STREAM_REQUEST 
 
t=42627 [st=42626]  +HTTP_TRANSACTION_SEND_REQUEST [dt=2] 
 
t=42627 [st=42626]  HTTP_TRANSACTION_SEND_REQUEST_HEADERS 
 
          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1 
 
           Host: qa.tieba.baidu.com 
 
           Connection: keep-alive 
 
           Accept: application/json, text/plain, */* 
 
           User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
 
           Referer: http://qa.tieba.baidu.com/project/ 
 
           Accept-Encoding: gzip, deflate, sdch 
 
           Accept-Language: en-US,en;q=0.8 
 
           Cookie: [268 bytes were stripped] 
 
t=42629 [st=42628]  -HTTP_TRANSACTION_SEND_REQUEST 
 
t=42629 [st=42628]  +HTTP_TRANSACTION_READ_HEADERS [dt=112] 
 
t=42629 [st=42628]  HTTP_STREAM_PARSER_READ_HEADERS [dt=112] 
 
t=42741 [st=42740]  HTTP_TRANSACTION_READ_RESPONSE_HEADERS 
 
          --> HTTP/1.1 200 OK 
 
           Date: Fri, 02 Jan 2015 09:51:48 GMT 
 
           Content-Type: application/json; charset=UTF-8 
 
           Transfer-Encoding: chunked 
 
           Connection: keep-alive 
 
           Cache-Control: no-cache 
 
           tracecode: 31079600320335034634010217 
 
           tracecode: 31079600320537995786010217 
 
           Server: Apache 
 
t=42741 [st=42740]  -HTTP_TRANSACTION_READ_HEADERS 
 
t=42741 [st=42740]  HTTP_CACHE_WRITE_INFO [dt=0] 
 
t=42741 [st=42740]  HTTP_CACHE_WRITE_DATA [dt=0] 
 
t=42741 [st=42740]  HTTP_CACHE_WRITE_INFO [dt=0] 
 
t=42741 [st=42740]  URL_REQUEST_DELEGATE [dt=0] 
 
t=42741 [st=42740] -URL_REQUEST_START_JOB 
 
t=42741 [st=42740] URL_REQUEST_DELEGATE [dt=0] 
 
t=42741 [st=42740] HTTP_TRANSACTION_READ_BODY [dt=0] 
 
t=42741 [st=42740] HTTP_CACHE_WRITE_DATA [dt=0] 
 
t=42741 [st=42740] HTTP_TRANSACTION_READ_BODY [dt=0] 
 
t=42741 [st=42740] HTTP_CACHE_WRITE_DATA [dt=0] 
 
t=42742 [st=42741] -REQUEST_ALIVE

संपादित करें: संबंधित मुद्देIssue 447463: Chrome-network: Long delay before RST message on stale sockets results in slow page loads.

Answer 1

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

क्रोम आपको इस सीमा को बदलने की अनुमति नहीं देता है। यह वास्तव में नहीं होना चाहिए। यदि आप इस सीमा के बारे में और जानना चाहते हैं, और अन्य ब्राउज़रों के लिए सीमाएं क्या हैं, तो आप this article पढ़ सकते हैं।

कारण यह सीमा शायद ही कभी एक समस्या है क्योंकि एक ही मेजबान के लिए कई HTTP अनुरोधों को समान रूप से समान रूप से भेजा जाता है, अधिमानतः उसी टीसीपी कनेक्शन पर।

इस समस्या अक्सर आप के लिए होता है, तो कारण हो सकता है:

1. सर्वर लगातार TCP कनेक्शन का समर्थन नहीं करता: समस्या केवल जब एक विशेष सर्वर तक पहुँच रहा, कारण हो सकता है होता है हो सकता है कि क्रोम समांतर कनेक्शन पर एकाधिक संसाधन (जैसे छवियों, सीएसएस फ़ाइलें, आदि) ला रहा हो। चूंकि, आपके मामले में, सर्वर आपके स्थानीय नेटवर्क पर है, तो आप सर्वर के व्यवस्थापक से लगातार टीसीपी कनेक्शन के लिए समर्थन जोड़ने के लिए कह सकते हैं।यदि आप प्रॉक्सी सर्वर के पीछे काम कर रहे हैं, तो एक साथ कई फ़ाइलों को डाउनलोड या साइटों जो एक TCP कनेक्शन खुला अपने problem.To का कारण यह से छुटकारा पाने के हो सकता है रखने खोलने,:

2. एकाधिक लगातार कनेक्शन खुले हैं आप बस इतना कर सकते हैं कि कई चीजें एक साथ डाउनलोड न करें (या यदि आपको करना है तो एक अलग ब्राउज़र में डाउनलोड करें)।

पुनश्च: त्रुटि net_error = -101 (ERR_CONNECTION_RESET) अमान्य हेडर के कारण नहीं है, यह समय समाप्ति की वजह से है सर्वर से कुछ पिछले कनेक्शन बंद होने की प्रतीक्षा।

Answer 2

इसी तरह की समस्या यहां और ऐसा प्रतीत होता है कि थोड़ी देर के बाद, लगभग 3 मिनट सॉकेट क्रोम का उपयोग करने की कोशिश कर रहा है ओएस द्वारा बंद (मुझे लगता है)।

यह क्रोमियम मंच में भी एक बग के रूप में सूचीबद्ध है। मैं कुछ प्रकार के "रख-रखाव" तंत्र की कमी का अनुमान लगा रहा हूं .: https://code.google.com/p/chromium/issues/detail?id=447463

मेरा त्रुटि संदेश थोड़ा अलग है लेकिन यह मेरे आवेदन के कारण SSL पर कॉल करने के कारण हो सकता है। यहाँ है कि मैं क्या क्रोम में देखते है: // net-internals:

पहले क्रोम एक मौजूदा सॉकेट पाता है और अनुरोध यह (HTTP_STREAM_JOB) से संबद्ध है: तो फिर (URL_REQUEST) में वापस

t=1572 [st=0] HTTP2_SESSION_POOL_FOUND_EXISTING_SESSION 
        --> source_dependency = 1347215 (HTTP2_SESSION) 
    t=1572 [st=0] HTTP_STREAM_JOB_BOUND_TO_REQUEST 
        --> source_dependency = 1348612 (URL_REQUEST) 
    t=1572 [st=0] -HTTP_STREAM_JOB 

आप देखेंगे यह समय के लिए बाहर, टी-समय में 10 सेकंड चूक ध्यान दें = 1572 टी के लिए = 11,573:

t= 1572 [st= 0] HTTP2_SESSION_SEND_DATA 
         --> fin = true 
         --> size = 48 
         --> stream_id = 3 
    t= 1572 [st= 0] HTTP2_SESSION_UPDATE_SEND_WINDOW 
         --> delta = -48 
         --> window_size = 2147483551 
    t=11573 [st=10001] HTTP2_SESSION_CLOSE 
         --> description = "Failed ping." 
         --> net_error = -352 (ERR_SPDY_PING_FAILED) 

जाहिर है वहाँ एक समय समाप्ति जब क्रोम मौजूदा सॉकेट पर विंडो का आकार समायोजित करने के लिए प्रयास करता है। मुझे लगता है कि यह सॉकेट पर निष्क्रियता के कारण है।

मैं अभी भी 60 सेकंड अंतराल पर कुछ प्रकार के दिल की धड़कन अनुरोध को लागू करने की कोशिश करने जा रहा हूं ताकि यह देखने के लिए कि समस्या अभी भी बनी हुई है या नहीं। मैं परिणामों के साथ एक अद्यतन पोस्ट करूंगा।

अद्यतन:

जोड़ा जावास्क्रिप्ट को निम्नलिखित कोड है कि हर पृष्ठ पर लोड कर रहा है। यह सार्वजनिक जड़ से एक खाली एचटीएमएल दस्तावेज़ पुनर्प्राप्त कर रहा है:

$(document).ready(function() { 
     $.keepalive =  
       setInterval(function() { 
        $.ajax({ 
         url: '/ping.html', 
         cache: false 
        });   
       }, 60000);  
    }); 

यह मदद की है करने के लिए प्रकट होता है यहां तक ​​कि बीच 'असली' लगभग 6 मिनट दिखा नीचे दिए गए नमूना के साथ खुला सॉकेट रखने कॉल:

60 सेकंड अंतराल में 570 बी प्रति कॉल पर पिंग कॉल प्रति 24 घंटे (प्रति ब्राउज़र सत्र) के लगभग 800 किलो बैंडविड्थ उपयोग को जोड़ देगा। मुझे यकीन नहीं है कि सर्वर पर कितना सीपीयू ओवरहेड होगा।

तुलना के लिए, इससे पहले कि: एक बेहतर समाधान हो करने के लिए

वहाँ है, लेकिन मैं अभी तक एक लगाने में सक्षम नहीं किया गया है।