javascript - log - network google chrome

solicitud detenida por un largo tiempo de vez en cuando en cromo

Question

La solicitud de Ajax se detuvo ocasionalmente durante mucho tiempo en Chrome.

Finalmente logré reproducirlo y guardar todos los datos relacionados necesarios para publicar aquí si alguien pudiera ayudarme.

La línea de tiempo de Chrome Dev Tool muestra la solicitud detenida para 42.62s, como muestra la siguiente captura de pantalla:

y dentro de la página chrome://net-internals/#events (para el registro de eventos, por favor, dirígete al final) encontré que la mayoría del tiempo cuesta dos eventos:

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

ambos obtienen ERR_CONNECTION_RESET .

Creo que el error es la razón por la cual la solicitud se estancó por tanto tiempo.

Cualquiera podría explicar los errores?

A CONTINUACIÓN ES EL REGISTRO DE EVENTOS PARA LA SOLICITUD, también exporto los eventos completos como json puede obtener desde here luego restaurar dentro de la página Chrome chrome://net-internals/#events . tenga en cuenta que la URL de solicitud es interna, por lo que tal vez no pueda acceder desde la red pública:

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

EDITAR: problema relacionado Problema 447463: Chrome-network: un retraso prolongado antes de que el mensaje RST en los sockets obsoletos genere cargas de página lentas.

Answer 1

Problema similar aquí y parece que después de un tiempo, aproximadamente 3 minutos un socket Chrome está tratando de usar está cerrado (supongo) por el sistema operativo.

Esto también aparece como un error en el foro de cromo. Adivino la falta de algún tipo de mecanismo de "mantener vivo" .: https://code.google.com/p/chromium/issues/detail?id=447463

Mi mensaje de error es ligeramente diferente, pero podría deberse a que mi aplicación realiza las llamadas a través de SSL. Esto es lo que veo en chrome: // net-internals:

First Chrome encuentra un socket existente y la solicitud está asociada con él (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

Luego, de vuelta en (URL_REQUEST), verá que se agota el tiempo de espera, tenga en cuenta el lapso de 10 segundos en el tiempo desde t = 1572 hasta 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)

Claramente, hay un tiempo de espera cuando Chrome intenta ajustar el tamaño de la ventana en el socket existente. Supongo que esto se debe a la inactividad en el socket.

Voy a tratar de implementar algún tipo de solicitud de latido en un intervalo de quizás 60 segundos para ver si el problema persiste. Publicaré una actualización con resultados.

ACTUALIZAR:

Se agregó el siguiente código a javascript que está cargado en cada página. Esto es recuperar un documento html vacío de la raíz pública:

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

Esto parece haber ayudado a mantener el socket abierto incluso con el ejemplo siguiente mostrando aproximadamente 6 minutos entre llamadas "reales":

A 570B por llamada en intervalos de 60 segundos, la llamada ping agregaría alrededor de 800kb de uso de ancho de banda por 24 horas (por sesión de navegador). No estoy seguro de cuánta sobrecarga de CPU en el servidor esto causarÃa.

Para comparar, ANTES:

Tiene que haber una solución mejor, pero aún no he podido encontrarla.

Answer 2

Una vez encontré un problema similar. La causa del problema es que cada navegador tiene un límite para la cantidad máxima de conexiones TCP a un servidor. Para cromo, el límite es seis. El problema es más prominente cuando está usando un servidor proxy, porque todas las solicitudes van al mismo servidor (el servidor proxy).

Chrome no te permite cambiar este límite. No debería de hecho. Si desea saber más acerca de por qué existe este límite y cuáles son los límites para otros navegadores, puede leer este artículo .

La razón por la que este límite rara vez es un problema es porque varias solicitudes HTTP al mismo host se envían principalmente de forma consecutiva, en lugar de de forma paralela, preferiblemente a través de la misma conexión TCP.

Si este problema le ocurre con frecuencia, entonces la razón podría ser:

1. El servidor no es compatible con la conexión TCP persistente: si el problema ocurre solo al acceder a un servidor en particular, la razón podría ser que Chrome está buscando recursos múltiples (como imágenes, archivos CSS, etc.) en conexiones paralelas. Dado que, en su caso, el servidor se encuentra en su red local, le recomendamos que solicite al administrador del servidor que agregue soporte para conexiones TCP persistentes.

2. Múltiples conexiones persistentes están abiertas: si está trabajando detrás de un servidor proxy, entonces la descarga de múltiples archivos simultáneamente o la apertura de sitios que mantienen abierta una conexión TCP podría ser la causa de su problema. Para deshacerse de él, todo lo que puede hacer es no descargue muchas cosas simultáneamente (o descargue en un navegador diferente, si es necesario).

PD: El error net_error = -101 (ERR_CONNECTION_RESET) no se debe a encabezados no válidos, es por el tiempo de espera, esperando a que se cierre alguna conexión previa al servidor.