8

16027.8scheda Developer Tool Chrome Web Network dice richieste Dojo AJAX stanno prendendo circa 44 anni per completare

la scheda Rete Chrome nei Sviluppo Web mostra che un gruppo di mie richieste AJAX stanno prendendo 16027.8 giorni per essere completato. Questo è ... non quanto tempo stanno prendendo.

Posso replicarlo su più macchine e in entrambi gli ambienti di sviluppo e produzione. Ciò accade per tutte le richieste Dojo AJAX che si verificano onload. Non succede per altre webapp o richieste di terze parti (come l'accesso AJAX o Facebook).

Che cosa sta succedendo? Il nostro server in qualche modo sta rovinando tutto? È un bug negli strumenti di chrome dev (è quasi certamente, giusto?), E se sì, c'è qualcosa che può essere fatto al riguardo? Rende la cascata visuale piuttosto inutile, come puoi immaginare.

Modifica: in base alle nuove informazioni, questo sembra essere un problema comune con i siti IBM Websphere Commerce. Che dire del server o del codice potrebbe causare questo? Guardate qui per gli esempi:

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

Edit 2: Questo problema è stato risolto nella versione più recente di Chrome.

+1

Latenza abbastanza buona per quella lunga di una richiesta. – Adam

+1

Questo è Chrome versione 31.0.1650.57 m su Windows 7, se questo è di aiuto. – MattDiamant

+0

Hai provato a farlo funzionare con tutti i componenti aggiuntivi disabilitati nel browser? – epascarello

risposta

7

Questo problema non è correlato al framework o al server Web. Il problema interessa la versione 31.0.1650.57 del browser Chrome.

Ora il problema è stato risolto e verrà consegnato con il successivo aggiornamento del canale stabile.Fix diff

Se è necessario risolvere urgentemente, è possibile aggiornare alla versione del canale di sviluppo. Instructions

Vedere this issue per ulteriori dettagli.

2

Molto strano. In grado di ricreare su Chrome 31.0.1650.57 su OSaver Mavericks pure. Testato con collegamento ikea, notato che Chrome ha segnalato 16028.7 giorni, 41 ms di latenza per la risorsa /us/en/iows/tealium.

Charles delega mostra queste intestazioni:

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 

L'applicazione proxy (Charles) riporta tale tempo dispari - si vede 40ms.

Il collegamento lavieenrose.com ha causato a Chrome la notifica del tempo di 16028.7 giorni ... che sembra essere comune. Charles mostra:

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 

La mia conclusione è che non è un problema di risposta del server o le intestazioni. Penso che questo sia un problema degli strumenti di sviluppo Chromium o WebKit.

Ecco HEAD dell'oggetto JS strumenti di sviluppo che rappresenta la richiesta HTTP che rese dalla scheda di rete:

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

che sto chiedendo circa la matematica in set endTime():

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; 
    } 
}, 

Ancora nessuna risposta, ma forse qualcuno con più informazioni su ciò che WebKit/Chromium DevTools può vedere questo ...

Problemi correlati