क्रोम नेटवर्क वेब डेवलपर टूल टैब का कहना है डोजो AJAX अनुरोध के आसपास 44 वर्ष ले जा रहे हैं वेब डेवलपर टूल में

Question

क्रोम नेटवर्क टैब पूरा करने के लिए पता चलता है कि मेरी AJAX के अनुरोधों का एक गुच्छा 16027.8 दिन ले जा रहे हैं पूरा करने के लिए। यह है ... वे कितने समय तक नहीं ले रहे हैं।

मैं इसे कई मशीनों पर और दोनों विकास और उत्पादन वातावरण में दोहरा सकता हूं। यह सभी Dojo AJAX अनुरोधों के लिए होता है जो onload हो रहा है। यह अन्य वेबैप या तृतीय पक्ष अनुरोधों (जैसे साइनइन AJAX या फेसबुक) के लिए नहीं होता है।

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

संपादित करें: नई जानकारी पर, यह आईबीएम वेबस्पेयर वाणिज्य साइटों के साथ एक आम समस्या प्रतीत होता है। सर्वर या कोड के बारे में क्या हो सकता है? यहाँ उदाहरण के लिए देखो:

http://www.ikea.com/us/en/catalog/categories/departments/kitchen/# http://www.lavieenrose.com/webapp/wcs/stores/servlet/LVER_10052_10001_-1 http://www.ferragamo.com/shop/en/usa

संपादित करें 2: यह समस्या क्रोम के नवीनतम संस्करण में तय हो गई है।

Answer 1

यह समस्या वेब ढांचे या सर्वर से संबंधित नहीं है। समस्या क्रोम ब्राउज़र संस्करण 31.0.1650.57 को प्रभावित करती है।

अब समस्या तय की गई है और अगले स्थिर चैनल अपडेट के साथ वितरित की जाएगी।Fix diff

यदि आपको तत्काल ठीक करने की आवश्यकता है, तो आप देव चैनल संस्करण में अपडेट कर सकते हैं। Instructions

अधिक जानकारी के लिए this issue देखें।

Answer 2

बहुत विषम। ओएसएक्स मैवरिक्स पर क्रोम 31.0.1650.57 पर भी पुन: निर्माण करने में सक्षम। परीक्षण किया गया w/ikea लिंक, क्रोम ने 16028.7 दिन, संसाधन /us/en/iows/tealium के लिए 41ms विलंबता की सूचना दी।

चार्ल्स प्रॉक्सी इन हेडर पता चलता है:

HTTP/1.1 304 Not Modified 
Content-Type: application/json 
Last-Modified: Mon, 18 Nov 2013 18:34:51 GMT 
Cache-Control: public, max-age=7200 
Date: Sat, 23 Nov 2013 00:32:26 GMT 
Connection: keep-alive 
Vary: Accept-Encoding 

प्रॉक्सी एप्लिकेशन (चार्ल्स) ऐसी कोई अजीब समय की रिपोर्ट - यह 40ms को दर्शाता है।

lavieenrose.com लिंक ने क्रोम को 16028.7 दिन के समय की रिपोर्ट करने का कारण बताया ... यह सामान्य में प्रतीत होता है। चार्ल्स पता चलता है:

HTTP/1.1 200 OK 
Date: Sat, 23 Nov 2013 00:46:37 GMT 
Server: IBM_HTTP_Server 
Last-Modified: Tue, 19 Jun 2012 13:05:34 GMT 
ETag: "5c487f-1a15-4c2d2f01a0380" 
Accept-Ranges: bytes 
Vary: Accept-Encoding 
Content-Encoding: gzip 
Content-Length: 1738 
Content-Type: application/x-javascript 

मेरा निष्कर्ष यह एक सर्वर प्रतिक्रिया या हेडर मुद्दा नहीं है। मुझे लगता है कि यह एक क्रोमियम या वेबकिट देव उपकरण मुद्दा है। set endTime() में

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/front_end/NetworkRequest.js

मैं गणित के बारे में सोच रहा हूँ:

set endTime(x) 
{ 
    if (this.timing && this.timing.requestTime) { 
     // Check against accurate responseReceivedTime. 
     this._endTime = Math.max(x, this.responseReceivedTime); 
    } else { 
     // Prefer endTime since it might be from the network stack. 
     this._endTime = x; 
     if (this._responseReceivedTime > x) 
      this._responseReceivedTime = x; 
    } 
}, 

यहाँ देव उपकरण जे एस उद्देश्य यह है कि http अनुरोध जो नेटवर्क टैब द्वारा प्रदान की गई का प्रतिनिधित्व करता है के प्रमुख है अभी तक कोई जवाब नहीं है, लेकिन शायद वेबकिट/क्रोमियम देवटूल के बारे में अधिक अंतर्दृष्टि वाला कोई व्यक्ति इसे देख सकता है ...