要求在镀铬中偶尔停滞很长时间

Way*_*you 51 javascript ajax networking google-chrome

Ajax请求偶尔会在chrome中停滞很长时间.

如果有人能帮助我的话,我终于设法复制了它并保存了发布在这里所需的所有相关数据.

Chrome开发工具的时间线显示停止了42.62秒的请求,如以下屏幕截图所示: 在此输入图像描述

chrome://net-internals/#events(对于事件日志,请到最后)页面我发现最多的时间是由两个事件花费:

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

都搞定了ERR_CONNECTION_RESET.

在此输入图像描述

我认为错误是请求停滞这么久的原因.

任何人都可以解释错误?

以下是请求的事件日志,我还将完整事件导出为json,您可以从此处获取,然后在Chrome 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
Run Code Online (Sandbox Code Playgroud)

编辑:相关问题 问题447463:Chrome-network:陈旧套接字上的RST消息之前的长延迟导致页面加载缓慢.

Tan*_*may 18

我曾经遇到过类似的问题.问题的原因是每个浏览器都限制了到服务器的最大TCP连接数.对于chrome,限制为6.当您使用代理服务器时,问题更加突出,因为所有请求都是同一台服务器(代理服务器).

Chrome不允许您更改此限制.事实上它不应该.如果您想了解更多关于此限制存在的原因以及其他浏览器的限制,您可以阅读本文.

此限制很少出现问题的原因是因为对同一主机的多个HTTP请求主要是连续发送,而不是并行发送,最好是在同一TCP连接上发送.

如果您经常遇到此问题,原因可能是:

  1. 服务器不支持持久性TCP连接:如果仅在访问特定服务器时出现问题,原因可能是chrome在并行连接上获取多个资源(如图像,CSS文件等).因为在您的情况下,服务器位于本地网络上,您可能需要请求服务器的管理员添加对持久TCP连接的支持.

  2. 多个持久连接是打开的:如果您在代理服务器后面工作,然后同时下载多个文件或打开保持TCP连接打开的站点可能是您的问题的原因.为了摆脱它,您所能做的就是不同时下载许多东西(或者如果必须,可以在不同的浏览器中下载).

PS:错误net_error = -101(ERR_CONNECTION_RESET)不是由于标头无效,而是因为超时,等待一些先前连接到服务器关闭.

  • 我不在代理服务器后面.这个问题发生在我们已经确定的几十台主机上,而不是大多数. (2认同)

td-*_*bda 9

类似的问题在这里看来,经过一段时间后,操作系统关闭(我假设)套接字铬试图使用大约3分钟.

这也被列为铬论坛中的一个错误.我猜测缺乏某种"保持活力"的机制:https: //code.google.com/p/chromium/issues/detail?id = 447463

我的错误消息略有不同,但可能是由于我的应用程序通过SSL进行调用.这是我在chrome:// net-internals中看到的内容:

第一个chrome找到一个现有套接字并且请求与它相关联(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
Run Code Online (Sandbox Code Playgroud)

然后回到(URL_REQUEST)你会看到它超时,注意从t = 1572到t = 11573的10秒时间流逝:

    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)
Run Code Online (Sandbox Code Playgroud)

显然,当chrome尝试调整现有套接字上的窗口大小时会出现超时.我认为这是由于套接字不活动造成的.

我将尝试以大约60秒的间隔实施某种心跳请求,看看问题是否仍然存在.我会发布一个结果更新.

更新:

将以下代码添加到每个页面上加载的javascript中.这是从公共根检索一个空的html文档:

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

这似乎有助于保持套接字打开,即使下面的示例显示"实际"呼叫之间大约6分钟:

结果

在60秒间隔的每次呼叫570B处,ping呼叫将每24小时(每个浏览器会话)增加大约800kb的带宽使用.我不确定服务器上会产生多少CPU开销.

为了比较,BEFORE:

在改变之前

必须有一个更好的解决方案,但我还没有找到一个.