[IE] [TS 2] Netzwerkprobleme

  • Article

Hier nun Teil 2 meiner Blogserie zum Troubleshooting des Internet Explorers.

Heute möchte ich mich mit dem allgemeinen Thema “Netzwerkprobleme” beschäftigen.

“Man ist der IE heute wieder laaaangsam” kann man ab und an mal in Foren oder FB lesen, doch eigentlich ist gar nicht der IE langsam, sondern das Netzwerk. Aber was genau langsam ist und ob/wie man dies beheben kann ist nicht immer einfach.

Mit älteren IE Versionsn (<9) benötigt man für das TS 3rd party Anwendungen, daher erkläre ich das prinzipielle Vorgehen anhand des IE9 und seines eingebauten Netzwerksniffers:

Bevor ich in das eigentliche TS einsteige, hier eine allgemeine Beschreibung wie das Laden und Anzeigen einer Seite theoretisch funktioniert [grob, soll keine detallierte und vollständige Auflistung sein]:

  1. Der User gibt eine URL in die Adresszeile ein oder klickt einen Link
  2. Der Internet Explorer überprüft
    1. Zu welcher Zone die aufgerufene Adresse gehört
    2. Welchen “Weg” der Aufruf gehen muss (sprich direkt oder Proxy)
  3. Schickt den GET Request auf den richtigen Weg
  4. Wartet (i.d.R. max 30s) auf eine Antwort [Stw.: Timeout]
  5. Reagiert auf die Antwort ggf. mit einem erneuten Request zwecks Authentifizierung und/oder Verschlüsselung
  6. Bekommt das HTML File und fängt parallel dazu an dieses Abzuarbeiten
  7. Wenn in dem HTML andere Dateien (z.B. JS, CSS oder Bilder) angegeben werden wird die Abarbeitung unterbrochen und diese Dateien angefordert. Bei JS wird auch darauf gewartet, bis diese vollständig angekommen sind (vgl.: Link JavaScript files at the end of the HTML document) und das kann u.U. schon mal etwas dauern, je nach Größe und Server von dem das File kommt.
    Es werden hierbei nicht “unendlich” viele gleichzeitige Verbindungen zu dem Server aufgebaut. Dies dient dem Schutz der betroffenen Netzwerkkomponenten – also Router, Proxy, Server – daher haben die Browser hier eine max. Anzahl an gleichzeitig genutzten Verbindungen, dies wurde auch in den HTTP Standards eingebaut, vgl. hierzu: MaxConnectionsPerServer und WinInetVerbindungen)
  8. Sobald alle Daten angekommen sind, werden die Styles auf das DOM angewendet und das JS ausgeführt.
  9. Während des gesamten Prozesses können Browser Helper Objekte (BHO) und/oder ActiveX Erweiterungen Eingreifen und das Verhalten beeinflussen, zu dem Performance Aspekt aber in einem anderen Post.

Hier gibt es viele Punkte, an denen “etwas schiefgehen” kann.

Um der Ursache auf die Schliche zu kommen öffnet man nun also die “F12 Tools” oder auch “Developer Tools” genannt => einfach F12 drücken oder über Menü->Extras->F12 developer Tools aufrufen und in den Reiter “Netzwerk wechseln”. Dort nun “Start Capturing” drücken und anschließend die Seite reloaden, dann erhält man z.B. dieses Ergebnis:

image

Zu Beginn ist vor allem die Spalte “Timings” wichtig, um zu sehen, wo es zu größeren Verzögerungen kommt.

In dem obigen Beispiel kann man sehr schön sehen, dass

  1. Der erste Request selber bis zur Antwort schon “relativ” lange (hier 250ms) brauchte
  2. Dieser Request auf das HTML Dokument für die Übertragung der 111kb 1,29s gebraucht hat, zwar nicht enorm, aber doch für heutige Zeiten relativ lang

Als nächstes kann man erkennen, dass erst nach dem Fertigstellen des letzten Javascript Files (10. von oben, 237kb in 0,92s) mit dem Laden der meisten Bilder angefangen wurde, was die insg. Dauer für die vollständig geladene Seite deutlich erhöht hat.

Anmerkung für Devs: Unnötige JS, bzw. zum ersten Aufruf nicht benötigte JS in eine (oder mehrere Dateien auslagern und am Ende des HTML Dokuments laden!)

Im Bild lässt sich auch sehr schön die von meinem IE eingestellte maximale Anzahl an gleichzeitigen Verbindungen “erahnen” [Na, kommt einer drauf? Gerne als Kommentar mit Begründung!]

Über diesen Weg kann ich auch sehr schön erkennen, ob und wann ein Server reagiert und darüber ggf. meine eigene Webseite optimieren.

Im Bild sind außerdem zwei mal “Aborted” Dateien zu sehen, errät jemand, warum diese Aborted wurden? [und nein, liegt nicht am Proxy! Winking smile In einem der folgenden Beiträgen werde ich darauf näher eingehen.]

Mithilfe dieses Netzwerksniffers ist es demnach relativ simpel einfache Netzwerkprobleme zu erkennen – insb. über die grafische Darstellung der Zeit. Bei komplexeren Problemen (Switches running wild, oder fehlerhaft Konfigurierten Netzwerkkomponenten, müsste dann doch ein komplexerer Netzwerksniffer (z.B. Netmon) eingesetzt werden, wobei die Analyse der Daten damit aufwändiger wird und am besten durch erfahrene Netzwerktechniker erfolgen sollte.

 

Zurück zur Übersicht der Serie

 

Bis zum nächsten Post

Es ist schwierig stillzuhalten, wenn man nichts zu tun hat. A. Schopenhauer

 

-Stephanus