web-dev-qa-db-ja.com

chromeで時々リクエストが長時間停止する

AjaxリクエストがChromeで長時間停止することがありました。

最終的に私はそれを再現し、誰かが私を助けてくれればここに投稿するために必要なすべての関連データを保存することができました。

Chrome Dev Toolのタイムラインには、次のスクリーンキャプチャが示すように、42.62秒間停止したリクエストが表示されます。 enter image description here

chrome://net-internals/#events（イベントログの場合は最後に移動してください）ページ内で、2つのイベントによるコストが最も高いことがわかりました。

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

両方ともERR_CONNECTION_RESETを取得します。

enter image description here

このエラーが、リクエストが長い間停止した理由だと思います。

誰でもエラーを説明できますか？

ISリクエストのイベントログに続いて、 here から取得できるjsonとしてイベント全体をエクスポートし、Chrome chrome://net-internals/#eventsページ内で復元します。リクエストURLは内部であるため、パブリックネットワークからはアクセスできない可能性があります。

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

編集：関連する問題問題447463：Chromeネットワーク：古いソケットのRSTメッセージの前に長い遅延が発生するとページの読み込みが遅くなります。

javascriptajaxgoogle-chromenetworking
49
Wayou

私はかつて同様の問題に遭遇しました。この問題の原因は、すべてのブラウザーがTCPサーバーへの接続の最大数に制限があることです。クロムの場合、制限は6です。問題は、すべての要求が同じサーバー（プロキシサーバー）に送信されるため、プロキシサーバー。

Chromeでは、この制限を変更することはできません。実際にはそうではありません。この制限が存在する理由、および他のブラウザーの制限について詳しく知りたい場合は、 この記事 を参照してください。

この制限が問題になることはめったにない理由は、同じホストへの複数のHTTP要求が、並列ではなく、できれば同じTCP接続を介して、ほとんど連続して送信されるためです。

この問題が頻繁に発生する場合は、次の理由が考えられます。

  1. サーバーは永続的なTCP connection：をサポートしていません。問題が特定のサーバーにアクセスするときにのみ発生する場合、 chromeは、並列接続で複数のリソース（画像、CSSファイルなど）を取得しています。あなたの場合、サーバーはローカルネットワーク上にあるので、サーバーの永続的なTCP接続のサポートを追加する管理者。

  2. 複数の永続的な接続が開いています：プロキシサーバーの背後で作業している場合、複数のファイルを同時にダウンロードするか、TCP接続が開いていることが問題の原因である可能性があります。それを取り除くためにできることは、多くのものを同時にダウンロードしないことです（または、必要に応じて別のブラウザーでダウンロードすることです）。

PS：エラーnet_error = -101（ERR_CONNECTION_RESET）は期限切れではありません無効なヘッダーは、タイムアウトが原因で、サーバーへの以前の接続が閉じるのを待っています。

16
Tanmay

ここで同様の問題があり、しばらくすると、約3分後にソケットchromeが使用しようとしています）がOSによって閉じられた（と思われます）ようです。

これは、クロムフォーラムにもバグとしてリストされています。何らかの「キープアライブ」メカニズムが不足していると思います。 https://code.google.com/p/chromium/issues/detail?id=44746

エラーメッセージは若干異なりますが、アプリケーションが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

（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)

chrome既存のソケットのウィンドウサイズを調整しようとすると、タイムアウトが発生します。これは、ソケットの非アクティブが原因であると考えられます。

おそらく60秒間隔で何らかのハートビート要求を実装して、問題が引き続き発生するかどうかを確認します。結果の更新を投稿します。

更新：

すべてのページにロードされるjavascriptに次のコードを追加しました。これは、パブリックルートから空のhtmlドキュメントを取得しています。

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

これは、以下のサンプルが「実際の」呼び出しの間に約6分を示している場合でも、ソケットを開いたままにしておくのに役立ちました。

Result

60秒間隔でコールごとに570Bの場合、pingコールは24時間ごと（ブラウザセッションごと）に約800kbの帯域幅使用量を追加します。これがサーバーでどれほどのCPUオーバーヘッドを引き起こすかはわかりません。

比較のために、BEFORE：

Before changes

より良い解決策がなければなりませんが、私はまだそれを見つけることができませんでした。

9
td-lambda