richiesta in stallo per un lungo periodo di tempo in cromo

Question

richiesta Ajax a volte bloccata per lungo tempo in cromo.

Sono finalmente riuscito a riprodurlo e salvare tutti i dati relativi necessari per postare qui se qualcuno potesse aiutarmi.

La cronologia di Chrome Dev strumento mostra la richiesta in fase di stallo per 42.62s come la seguente schermata mostra:

e all'interno della chrome://net-internals/#events (per gli eventi di registro si prega di testa fino alla fine) pagina ho trovato il più tempo è costo da due eventi:

• + HTTP_TRANSACTION_READ_HEADERS [dt = 21301]
• + HTTP_TRANSACTION_READ_HEADERS [dt = 21304]

entrambi ottengono ERR_CONNECTION_RESET.

penso che l'errore è il motivo per cui la richiesta in fase di stallo per così tanto tempo.

Qualcuno potrebbe spiegare gli errori?

A SEGUIRE IL REGISTRO EVENTI PER LA RICHIESTA, esporto anche gli eventi completi come JSON che è possibile ottenere da here quindi ripristinare all'interno della pagina Chrome chrome://net-internals/#events. notare che la richiesta di URL è interno l'accesso in modo forse non posso da rete pubblica:

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

EDIT: connessi problemaIssue 447463: Chrome-network: Long delay before RST message on stale sockets results in slow page loads.

Answer 1

Una volta ho incontrato un problema simile. La causa del problema è che ogni browser ha un limite al numero massimo di connessioni TCP a un server. Per il cromo, il limite è sei. Il problema è più evidente quando si utilizza un server proxy, poiché tutte le richieste vanno sullo stesso server (il server proxy).

Chrome non consente di modificare questo limite. Non dovrebbe in effetti. Se vuoi sapere di più sul perché questo limite esiste e quali sono i limiti per gli altri browser, puoi leggere this article.

Il motivo per cui questo limite è raramente un problema è perché più richieste HTTP allo stesso host vengono inviate per lo più, anziché in parallelo, preferibilmente sulla stessa connessione TCP.

Se questo problema si verifica a voi di frequente, allora la ragione potrebbe essere:

1. Server non supporta la connessione TCP persistente: Se il problema si verifica solo quando si accede a un server particolare, il motivo potrebbe sia che Chrome stia recuperando più risorse (come immagini, file CSS, ecc.) su connessioni parallele. Dal momento che, nel tuo caso, il server si trova sulla tua rete locale, potresti chiedere all'amministratore del server di aggiungere il supporto per le connessioni TCP persistenti.

2. Molteplici connessioni persistenti sono aperte: Se si sta lavorando dietro un server proxy, quindi il download di più file contemporaneamente o siti che mantengono una connessione TCP aperta potrebbe essere la causa della vostra problem.To sbarazzarsi di esso di apertura, tutto quello che puoi fare è non scaricare più cose contemporaneamente (o scaricarle in un altro browser, se necessario).

PS: L'errore net_error = -101 (ERR_CONNECTION_RESET) non è a causa di intestazioni non valide, è a causa del timeout, in attesa di qualche connessione precedente al server per chiudere.

Answer 2

Problema simile qui e sembra che dopo un po ', circa 3 minuti che un socket chrome sta tentando di utilizzare è chiuso (presumo) dal sistema operativo.

Questo è elencato come un bug nel forum chromium pure. Sto indovinando la mancanza di una sorta di meccanismo "keep-alive" .: https://code.google.com/p/chromium/issues/detail?id=447463

Il mio messaggio di errore è leggermente diverso ma potrebbe essere dovuto alla mia applicazione che effettua le chiamate su SSL. Ecco quello che vedo in chrome: // net-internals:

Prima cromo trova un socket esistente e la richiesta è associato con esso (HTTP_STREAM_JOB):

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 

Poi di nuovo a (URL_REQUEST) si vedrà esso time out, notare l'intervallo di 10 secondi nel tempo da t = 1572 al t = 11573:

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) 

Chiaramente c'è un timeout quando tenta di cromo per regolare le dimensioni della finestra sulla presa esistente. Presumo che ciò sia dovuto all'inattività sul socket.

Ho intenzione di provare a implementare una sorta di richiesta heartbeat a intervalli di 60 secondi per verificare se il problema persiste. Pubblicherò un aggiornamento con i risultati.

UPDATE:

aggiunto il seguente codice javascript che è caricato in ogni pagina. Questo è il recupero di un documento HTML vuoto dalla radice pubblico:

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

Questo sembra aver contribuito mantenere il socket aperto anche con l'esempio qui sotto mostra circa 6 minuti tra "reale" chiama:

A 570B per chiamata in intervalli di 60 secondi, la chiamata ping aggiungerebbe circa 800 kb di utilizzo della larghezza di banda ogni 24 ore (per sessione del browser). Non sono sicuro di quanto sovraccarico della CPU sul server causerebbe questo.

Per confronto, la PRIMA:

Ci deve essere una soluzione migliore, ma non sono stato in grado di individuare ancora uno.