Seiten werden mit starker Verzögerung geladen

[Spacewalker]

In wievielen Foren schreibst Du sonst noch?

Reine Lese-Zugriffe sind schon noch etwas Anderes.

[PCS]

Da das Problem (fast) ausschließlich bei Usern vorkommt, welche mit 1&1 (in seltenen Fällen auch Vodafone) surfen, liegt zumindest die Vermutung nahe, dass die Ursache bei jenem Provider zu suchen sein müsste.

Wir können die Probleme in keiner Form nachstellen. Das Forum rennt. Und das gilt wohl für >95% der User. Von daher ist es schwer, etwas zu raten, außer einmal mit dem Provider zu sprechen...

[Jr1231]

Das ist kein dummer Spruch, sondern soll ein Hinweis sein, dass es durchaus nicht am Forum liegen muss.

Die allermeisten Mitglieder haben keine Probleme.

Daher vielleicht mal vor der eigenen Türe kehren. (Browsercache leeren, Router und Endgerät neu starten, etc.)

Mancher lässt sein Gerät monatelang ohne einen einzigen Neustart laufen.

Der mit Abstand häufigste Problemlöser in der IT ist "AEG". (Ausschalten, Einschalten, Geht wieder)

Endlich habe ich nach 35 Jahren als Informatiker doch noch etwas dazugelernt. Bist mein Held

[Spacewalker]

Und wenn ich Dir jetzt noch schreibe, dass Baden-Württemberg mit zwei "t" geschrieben wird, dann bist Du ganz platt.

[Spacewalker]

Da das Problem (fast) ausschließlich bei Usern vorkommt, welche mit 1&1 (in seltenen Fällen auch Vodafone) surfen, liegt zumindest die Vermutung nahe, dass die Ursache bei jenem Provider zu suchen sein müsste.

Wir können die Probleme in keiner Form nachstellen. Das Forum rennt. Und das gilt wohl für >95% der User. Von daher ist es schwer, etwas zu raten, außer einmal mit dem Provider zu sprechen...

Ich habe weder bei Netcologne, noch bei Vodafone (LTE) Probleme.

Gerade habe ich noch mal mein selten genutzes Android-Tablet angeworfen. Auch da geschieht der Seitenaufbau in Sekundenbruchteilen. Sowohl über WLAN (Netcologne) als auch über Mobile Daten (beim Tablet ist das O2)

[NicoH]

Das ist für mich auch nicht reproduzierbar, tritt aber bei iPad, iMac und MacBook auf. Provider ist die Telekom.

[NicoH]

Ich besuche mindestens zwei weitere Foren und ganz schön viele andere Seiten im www, aber *nirgendwo* sonst habe ich diese Timeouts.

[MacLeon]

Ich hatte auch noch keine Verbindungsprobleme. Provider: Telekom. Hardware: Apple.

[ligthning]

Das ist auch meine Konfiguration, dazu die beste FRITZ!Box. Das flutscht nur so

[pasta_hansel]

Das ist kein dummer Spruch, sondern soll ein Hinweis sein, dass es durchaus nicht am Forum liegen muss.

Die allermeisten Mitglieder haben keine Probleme.

Daher vielleicht mal vor der eigenen Türe kehren. (Browsercache leeren, Router und Endgerät neu starten, etc.)

Mancher lässt sein Gerät monatelang ohne einen einzigen Neustart laufen.

Der mit Abstand häufigste Problemlöser in der IT ist "AEG". (Ausschalten, Einschalten, Geht wieder)

Nachdem ich hier mal ordentlich durchgekehrt habe... Hat sich nichts geändert! Immer noch Vodafone zuhause, Telekom unterwegs, 1&1 im Geschäft.
Ladezeiten beim Aufruf und beim Posten oft deutlich verzögert.

Vielleicht ist es trotzdem nicht immer die eigene Tür.

In anderen Foren hab ich das Problem übrigens noch nicht gehabt!

Edit: Da der Post nach ca. 20 Sekunden immer noch nicht übertragen war, hab ich ein Zweites Mal auf „Antworten“ drücken müssen. Dann ging es, und so war es nicht das erste Mal.

[Ingo.L]

Treten die Probleme auch auf, wenn ihr das Forum in einen „private Tab“ aufruft?

[OvL]

Treten die Probleme auch auf, wenn ihr das Forum in einen „private Tab“ aufruft?

Bei mir ja.

[dj74]

Ich habe mal den Netzwerkverkehr mit Wireshark mitgeschnitten.



Sobald das Laden der Seiten hängt, werden von Wireshark jede Menge "TCP ZeroWindowProbe" aufgezeichnet (siehe https://osqa-ask.wireshark.org/quest...rowindow-probe).
Erst nach gut drei Minuten geht es nach einem Reset (RST) mit einem neuen TCP-Stream wieder weiter.

Der R-L-X-Server (85.13.147.42) sendet unmittelbar vor dem Auftreten des Fehlers eine Window-Size 0 an den Client. Das veranlasst den Client, keine weiteren Daten (Anfragen) mehr an den Server zu senden bis dieser die Window-Size wieder erhöht.
Nachdem dies aber nicht geschieht, prüft der Client in regelmäßigen Abständen, ob der Server vielleicht doch wieder erreichbar ist (das ist dann die aufgezeichnete "TCP ZeroWindowProbe").

Die Frage ist also, warum der R-L-X-Server eine Window-Size von 0 sendet. Dies kann z.B. auftreten, wenn die TCP-Buffer des Servers überlastet sind oder der Server aus Überlast (im TCP-Stack) den Client einbremsen will.
Somit ist dieser TCP-Stream so lange blockiert bis der Server von sich aus die Window-Size wieder hochsetzt oder ein Timeout auftritt und der Client einen neuen TCP-Stream startet; Dann geht das Spielchen wieder von vorne los.
Dieses Verhalten kann ich insbesondere dann beobachten, wenn ich mehrere parallele Tabs aufmache und verschiedene Seiten in schneller Folge aufrufe.

Das Problem liegt also nicht am Browser, was erklärt, warum alle Versuche mit Cache leeren, oder anderem DNS-Server nutz- und wirkungslos sind.

Ich vermute eher eine Überlastung des serverseiten Netzwerkstacks (oder einer davor geschalteten Firewall oder eines Loadbalancers) oder in der Webserverkonfiguration, die die Anzahl gleichzeitiger Verbindungen limitiert (und in eine Queue stellt).
Eine niedrige Systemlast (auf CPU- RAM- und HDD-Ebene) alleine sagt nicht aus, ob ein Server ggf. überlastet ist. Auch die Netzwerkschicht sollte in die Betrachtung mit einbezogen werden.

[Feuerzunge]

Hallo Jan,

wow, das ist fundiert - Danke!

Grüßle Dietmar

[Jr1231]

Danke Jan, tolle Analyse

[le0p0ld]

[henri_san]

Edit: Da der Post nach ca. 20 Sekunden immer noch nicht übertragen war, hab ich ein Zweites Mal auf „Antworten“ drücken müssen. Dann ging es, und so war es nicht das erste Mal.

So ist es bei mir bei jedem zweiten Post den ich bestätige.

Jan: mega, vllt. kann man ja so was feststellen

[buchfuchs1]

Provider: Vodafone
Keinerlei Probleme beim Seitenaufbau.
Ich bin da aber auch bescheiden und erwarte keine Warp-Moves.

[dj74]

Das Forum scheint nicht generell überlastet zu sein, denn wenn die Seiten ausgeliefert werden, dann werden sie an sich schnell geladen.
Wenn ich gaaaaanz langsam durch die Seiten klicke, geht es meist gut, aber sobald ich mal ein paar Seiten in kurzer Folge nacheinander aufrufe, z.B. Blättern in einem Thread, hängt das Ganze dann eben sehr lange oder läuft ins Timeout (ca. 3 min).

Am iPad habe ich inzwischen folgenden Workaround für mich gefunden:
Wenn der Aufruf hängt, aktiviere ich den Flugmodus kurz (und trenne somit die offenen TCP-Verbindungen) und deaktiviere ihn nach ein paar Sekunden wieder (somit werden neue TCP-Verbindungen aufgebaut).

[der_mo]

Das könnte ein Problem sein, habe schon öfters drauf hingewiesen:

Mixed Content: The page at '<URL>' was loaded over HTTPS, but requested an insecure element '<URL>'. This request was automatically upgraded to HTTPS, For more information see <URL>
VM163 190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen:2 Mixed Content: The page at 'https://www.r-l-x.de/forum/showthread.php/190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen?p=6499823#post6499823' was loaded over HTTPS, but requested an insecure element 'http://abload.de/img/hulule6fsj9.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no...out-https.html
VM163 190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen:2 Mixed Content: The page at 'https://www.r-l-x.de/forum/showthread.php/190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen?p=6499823#post6499823' was loaded over HTTPS, but requested an insecure element 'http://abload.de/img/hulule6fsj9.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no...out-https.html
VM163 190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen:2 Mixed Content: The page at 'https://www.r-l-x.de/forum/showthread.php/190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen?p=6499823#post6499823' was loaded over HTTPS, but requested an insecure element 'http://abload.de/img/hulule6fsj9.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no...out-https.html
VM163 190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen:1 Mixed Content: The page at 'https://www.r-l-x.de/forum/showthread.php/190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen?p=6499823#post6499823' was loaded over HTTPS, but requested an insecure element 'http://abload.de/img/hulule6fsj9.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no...out-https.html
VM163 190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen:1 Mixed Content: The page at 'https://www.r-l-x.de/forum/showthread.php/190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen?p=6499823#post6499823' was loaded over HTTPS, but requested an insecure element 'http://abload.de/img/hulule6fsj9.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no...out-https.html
VM163 190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen:1 Mixed Content: The page at 'https://www.r-l-x.de/forum/showthread.php/190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen?p=6499823#post6499823' was loaded over HTTPS, but requested an insecure element 'http://abload.de/img/hulule6fsj9.jpg'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no...out-https.html
2190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen?p=6499823:40 A parser-blocking, cross site (i.e. different eTLD+1) script, https://ajax.googleapis.com/ajax/lib...n-min.js?v=425, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
(anonymous) 190894-Seiten-werden-mit-starker-Verz%F6gerung-geladen?p=6499823:40


abgesehen davon geht´s bei mir sehr schnell:
82 requests
45.9 kB transferred
1.5 MB resources
Finish: 1.01 s
DOMContentLoaded: 759 ms
Load: 962 ms