Anfrage angehalten für eine lange Zeit gelegentlich in Chrom

Ajax-request gelegentlich angehalten für eine lange Zeit in chrome.

Ich es endlich geschafft, es kopiert, und speichern Sie alle zugehörigen Daten, die notwendig sind, hier zu posten, wenn jemand könnte mir helfen.

Der timeline aus Chrome Dev Tool zeigt die Anforderung angehalten für 42.62 s, wie der folgenden Screenshot zeigt:
Anfrage angehalten für eine lange Zeit gelegentlich in Chrom

und innerhalb der chrome://net-internals/#events (für die Veranstaltungen melden Sie bitte den Kopf zu Ende) - Seite fand ich am meisten Zeit Kosten, die durch zwei Ereignisse:

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

bekommen beide ERR_CONNECTION_RESET.

Anfrage angehalten für eine lange Zeit gelegentlich in Chrom

Ich denke, der Fehler ist der Grund, warum die Anforderung angehalten so lange.

Jedem konnte man erklären den Fehler?

FOLGENDEN IST DIE VERANSTALTUNGEN ANMELDEN, FÜR DIE ANFRAGE, ich habe auch den export der full-events als json erhalten Sie von hier dann wiederherstellen der Chrome - chrome://net-internals/#events Seite. Hinweis: die request-url intern ist, also vielleicht keinen Zugriff aus dem öffentlichen Netz:

HTML:

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:Problem im Zusammenhang Problem 447463: Chrom-Netzwerk: Lange Verzögerung, bevor die ERSTE Nachricht auf veraltete Steckdosen Ergebnisse in langsamen laden der Seite.

Ist das immer noch ein Problem? Ich habe versucht, den Besuch qa.tieba.baidu.com/release/... und Varianten wie qa.tieba.baidu.com/release und qa.tieba.baidu.com, aber alle timeout. Wenn Sie das surfen auf einem lokalen Netzwerk, schlage ich vor, Sie versuchen, die gleichen und sehen, ob die links-timeout zu. Bitte aktualisieren Sie uns.
die url intern ist der Zugriff, das ist, warum Sie bekommen timeout. aber das hat nichts zu tun mit diesem Thema.
Ich würde gerne wissen, ob 1) diese url mal, wenn Sie besuchen Sie es direkt, 2), was die Antwort-Header sind, wenn Sie besuchen Sie es direkt an (check mit FF oder Chrome), und 3) json, jsonp oder andere ajax-call?
mehrere Male versuchte, nicht zu vervielfältigen, die durch den Besuch direkt, so dass das problem möglicherweise verursacht durch ajax-Aufruf verwenden wir json als Antwort.
du eine Antwort bekommen? Ich bin auch mit dem gleichen problem.
noch nicht, aber Sie können einige nützliche Informationen aus dem chromium issue page code.google.com/p/chromium/issues/detail?id=447463
Ich habe ein ähnliches Problem mit Chrome auf die Entwicklung von angularJS. Manchmal, aber nicht immer, wenn ich aktualisieren Sie die Seite nachdem Sie die änderungen, die sich für index.html angehalten wird für bis zu 1,6 Minuten und dann ist alles fliegt vorbei. Es passiert nicht jedes mal und bisher hatte ich noch keine, es passiert in anderen Browsern und es ist uaually nachdem ich einige änderungen vorgenommen. Dies bedeutet, dass die Seite auf dem display wurde im Leerlauf für einige Zeit, während ich war Bearbeitung. Irgendwelche Ideen? Dies alles geschieht auf localhost.

InformationsquelleAutor Wayou | 2015-01-02

16

Ich einmal begegnet ein ähnliches problem. Die Ursache des Problems ist, dass jeder browser hat eine Grenze für die maximale Anzahl von TCP-verbindungen zu einem server. Für chrome, die Grenze ist sechs. Das problem wird deutlicher, wenn Sie einen proxy-server verwenden, da alle Anfragen gehen den gleichen server (proxy-server).

Chrome ermöglicht es Ihnen nicht um die Begrenzung zu ändern. Sollte es nicht in der Tat. Wenn Sie mehr darüber wissen möchten, warum diese Begrenzung existiert, und was sind die Grenzen für andere Browser, Sie können Lesen dieser Artikel.

Der Grund, warum dieses limit ist selten ein problem, weil mehrere HTTP-requests an den gleichen host sind meist hintereinander gesendet, anstatt parallel, vorzugsweise über die gleiche TCP-Verbindung.

Wenn dieses problem Auftritt, die Sie Häufig, dann könnte der Grund sein:
1. Server keine Unterstützung für die persistente TCP-Verbindung:, Wenn das problem nur beim Zugriff auf einen bestimmten server, der Grund könnte sein, dass sich chrome Holen mehrere Ressourcen (wie Bilder, CSS-Dateien, etc) auf parallelen verbindungen. Da in deinem Fall der server auf Ihrem lokalen Netzwerk haben, möchten Sie möglicherweise bitten Sie den administrator des Servers, um Unterstützung für persistente TCP-verbindungen.
2. Mehrere persistente verbindungen offen sind: Wenn Sie hinter einem proxy-server, dann das herunterladen mehrerer Dateien gleichzeitig oder öffnen von Websites, die eine TCP-Verbindung zu öffnen, möglicherweise die Ursache für Ihr problem.Um es loszuwerden, alles, was Sie tun können, ist kein download viele Dinge gleichzeitig (oder download in einem anderen browser, wenn Sie zu haben).
PS: Der Fehler net_error = -101 (ERR_CONNECTION_RESET) nicht aufgrund Ungültiger Header, es ist, weil der timeout-Zeit, warten einige frühere Verbindung, um den server zu schließen.
- Ich sehe das gleiche Verhalten, aber für meinen ersten laden der Seite, nicht einen AJAX-Aufruf, so dass es nicht ein problem mit der Verbindung begrenzen. Ich habe nur eine Verbindung zu der Website öffnen, die erste Anfrage.
- Sind Sie hinter einem proxy-server? Und tritt das problem occus nur für einen bestimmten host-oder ganze websites?
- Ich bin nicht hinter einem proxy-server. Das problem tritt auf, für ein paar Dutzend Rechner, die wir identifiziert haben, nicht für die meisten.
- gerade als die Diskussion in der chrome-Problem, das ich berichtet, scheint die vernünftige Erklärung ist, dass der browser mit ungültigen socket zum senden der Anfrage. die Begrenzung der tcp-Verbindung, die Sie erwähnt haben, ist eine weitere Möglichkeit, aber aus der log-Datei können wir nicht sagen.
- Ich bekomme dieses Verhalten bei sechs. ich bin laden Sie ein Skript im Kopf .. aber vorher .. iam tun xhr-Anfrage, in das head-element .. aber chrome scheint stall das xhr-Anforderung, bis das js-script ist fertig .. warum ? Sie sind unterschiedlichen Anforderungen und das Skript ist angehängt, nachdem das xhr ist gemacht.
- und ich habe weniger als sechs verbindungen
InformationsquelleAutor Tanmay
9

Ähnliches Problem hier und es scheint, dass nach einer Weile, ca 3 Minuten ein socket chrome versucht, zu verwenden ist geschlossen (wie ich vermute) durch das OS.

Dieser ist aufgeführt, wie ein Fehler in der Chrom-forum als auch. Ich vermute, Mangel an irgendeiner Art von "keep-alive" - Mechanismus.:
https://code.google.com/p/chromium/issues/detail?id=447463

Meine Fehlermeldung ist etwas anders, aber es könnte sein, aufgrund meiner Anwendung machen die Anrufe über SSL. Hier ist, was ich sehe in chrome://net-internals:

Ersten chrome findet eine vorhandene Steckdose und die Anfrage wird im Zusammenhang mit (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
```
Dann wieder in (URL_REQUEST), sehen Sie es mal aus, beachten Sie die 10-Sekunden-Zeitraffer in der Zeit von t=1572 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)
```
Klar ist es ein timeout, wenn chrome versucht, passen Sie die Größe des Fensters auf die vorhandenen sockel. Ich nehme an, dies ist aufgrund von Inaktivität auf den sockel.

Ich werde versuchen, zu implementieren, eine Art heartbeat-Anfrage bei vielleicht 60 sec-Intervall, um zu sehen, ob das Problem noch besteht. Ich poste ein update mit den Ergebnissen.

UPDATE:

Hinzugefügt, den folgenden code zu javascript, die geladen an jeder Seite. Dies ist das abrufen einer leeren html-doc aus dem öffentlichen root:
```
    $(document).ready(function() {
        $.keepalive =     
                setInterval(function() {
                   $.ajax({
                      url: '/ping.html',
                      cache: false
                   });         
                }, 60000);    
    });
```
Erscheint, haben dazu beigetragen, dass der socket öffnen, auch mit dem Beispiel unten zeigt ca 6 Minuten zwischen "real" nennt:

In 570B pro Anruf 60 Sek Abständen die ping-Aufruf hinzufügen würde, um 800kb der Bandbreitennutzung pro 24 Stunden (pro browser-Sitzung). Ich bin mir nicht sicher, wie viel CPU-overhead auf dem server verursachen würde.

Zum Vergleich VOR:

Da muss es eine bessere Lösung, aber ich habe nicht in der Lage zu suchen, die noch.

InformationsquelleAutor td-lambda

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.