IIS: So erkennen Sie, ob eine langsame Zeit aufgrund einer langsamen Netzwerkverbindung erforderlich ist


10

Laut http://support.microsoft.com/kb/944884 "kann der Wert des Zeitfelds höher sein als erwartet, wenn eine große Antwort oder große Antworten über eine langsame Netzwerkverbindung an einen Client gesendet werden".

Ich habe eine Situation, in der ein Client sagt: "Ich habe um 10:03:24 eine Anfrage an Ihren Webserver gesendet und es hat 20 Sekunden gedauert, warum?". Ich kann dies auch in den IIS-Protokollen sehen, aber das ASP.NET-Modul des Servers hat es als 100 ms lang protokolliert, und die CPU- und Festplattenzähler waren niedrig.

Ich vermute, dass es an einer langsamen Netzwerkverbindung liegt. Wie kann ich das beweisen?

Aktualisieren:

1) Dies sind SOAP-Webdienstanforderungen, daher keine eingebetteten Grafiken, sondern nur ein HTTP-POST mit einer einzelnen XML-Ergebnisseite.

2) Außerdem habe ich dies reproduziert, indem ich die Netzwerkgeschwindigkeit auf der Clientseite gedrosselt habe, und die Symptome sind genau gleich.

3) Das Problem tritt nur sporadisch auf, was bedeutet, dass dieselbe Anforderung für den Client normalerweise schnell, gelegentlich jedoch langsam ist. Ich kann das nur reproduzieren, indem ich das Netzwerk drossle. Die ASP.NET-Protokollierung des Servers zeigt es immer schnell an, aber die IIS-Protokollierung zeigt es langsam an, wenn der Client sagt, dass es langsam ist.

4) Ich habe nur Zugriff auf den Server und muss dem Client so viele Informationen wie möglich zur Verfügung stellen, damit er akzeptiert, dass das Problem nicht auf dem Server liegt, und weiß, welche Protokollierung / Tools auf dem Client ausgeführt werden müssen, um die Grundursache zu finden.


Sind diese Anforderungen normale Seitenaufrufe, die das Abrufen von Einbettungsgrafiken usw. erfordern? Oder handelt es sich um automatisierte Abfragen, die nur eine einzige Seite zurückgeben? Messen wir tatsächlich die Zeit zum Laden einer Seite oder die Zeit zum Beantworten einer einzelnen HTTP-Anfrage?
David Schwartz

Antworten:


4

Ich habe eine Situation, in der ein Client sagt: "Ich habe um 10:03:24 eine Anfrage an Ihren Webserver gesendet und es hat 20 Sekunden gedauert, warum?". Ich kann dies auch in den IIS-Protokollen sehen, aber das ASP.NET-Modul des Servers hat es als 100 ms lang protokolliert, und die CPU- und Festplattenzähler waren niedrig.

Ich vermute, dass es an einer langsamen Netzwerkverbindung liegt. Wie kann ich das beweisen?

Es beginnt mit der Suche nach Paket-Drops zwischen dem Browser Ihres Kunden und allen Quellen von Bildern / Skripten / HTML für die oben genannte Webseite. Wenn Sie konsistente Paketverluste feststellen, wissen Sie mit Sicherheit, dass im Netzwerk etwas repariert werden muss ... auch wenn es sich nur um eine überlastete Verbindung handelt. Paketverluste sind nicht der einzige Grund für ein langsames Netzwerk, aber meiner Erfahrung nach die häufigste Quelle. Andere Quellen könnten eine falsch konfigurierte Proxy- oder Cache-Engine sein. Leider kann ich hier nicht alle möglichen Netzwerkschuldigen auflisten.

Die Leute geben jedoch häufig dem Netzwerk die Schuld, obwohl die Geschwindigkeitsprobleme tatsächlich in ihrer eigenen Kontrolle liegen. Mögliche Erklärungen:

  • Angenommen, der HTML-Code für diese Seite wurde schlecht geschrieben und die erforderlichen Skripte werden in der falschen Reihenfolge geladen, sodass die gesamte Seite langsam gerendert wird, obwohl fast alle Ressourcen vorhanden waren.
  • Die Seite wartet auf eine Ressource, die einfach nicht vorhanden ist, und läuft während des Wartens ab.
  • Ein Skript befindet sich in einer langsamen Schleife, die für eine Weile blockiert
  • Eine Cache-Engine benötigt viel Zeit, um ein Bild zu liefern
  • Ihr CGI sucht in einer Datenbank nach etwas, und die Suche selbst ist langsam
  • Sie verwenden Google Analytics , wodurch die Schreibweise der Seite verlangsamt wird

Ich könnte weitermachen, aber der Punkt ist, dass Sie den genauen Grund dafür herausfinden müssen, warum die Seite selbst langsam ist. Ein fehlerhaftes Netzwerk ist möglich; Es ist auch möglich, dass andere Faktoren zur langsamen Leistung beitragen.

Um weiter zu diagnostizieren:

  • Wenn die Seite in Firefox gut geladen wird, ist die Registerkarte Netzwerk in Firebug Ihr Freund (Drücken Sie F12, gehen Sie zur Registerkarte Netzwerk und laden Sie die Seite neu). Firebug gibt Ihnen ein schönes Wasserfalldiagramm, wie die Seite geladen wird und wo die Verzögerungen liegenFirebug Wasserfall
  • Wenn die Seite in Chrome gut geladen wird, können Sie etwas Ähnliches tun ( CntlShiftIKlicken Sie auf die Registerkarte Netzwerk und laden Sie die Seite neu).Chrom
  • Wenn die Seite nur im IE unterstützt wird (übrigens, Schande für Ihre HTML-Entwickler), ist es am besten, jedes dieser ASP-Seitenelemente einzeln zu laden, curlbis Sie etwas finden, das viel zu langsam aussieht, und dann herauszufinden, warum dieses bestimmte Element ist langsam.

Übrigens verwendeten die Chrome- und Firefox-Beispiele eine CGI-Abfrage von Debian.org . Dies ist ein gutes Beispiel für eine Verzögerung, die durch eine CGI-Suche verursacht wird.

Wenn alles andere fehlschlägt, können Sie ein .pcapvon Wireshark erhalten und es durchlaufen lassen tcptrace. Obwohl tcptracees sehr gut ist, Paket-Dumps zu analysieren, gibt es keine Garantie dafür, dass Sie das Problem tcptraceallein isolieren können. In dieser Antwort finden Sie Informationen zur Verwendung der tcptraceDiagnose.


Siehe meine Updates oben. Während Ihre Informationen im allgemeinen Fall sehr nützlich sind, denke ich nicht, dass sie hier zutreffen. Die Seite ist nur zeitweise langsam und die Symptome sind nur reproduzierbar, wenn ich das Netzwerk auf der Clientseite drossle.
Jon

Die Wasserfalldiagramme in Firefox / Chrome unterstützen http-Post-Operationen sowie Curl ... Ich bin nicht sicher, wie Sie zu dem Schluss gekommen sind, dass die Informationen nicht zutreffen, aber es scheint, dass es sich nicht um eine vollständige Anwendung der Tools gegen die Problemdomäne handelt .
Mike Pennington

Firefox / Chrome sind clientseitige Tools. Ich habe nur Zugriff auf den Server und kann mit meinem eigenen Client keine Repro durchführen. Ich muss nur vom Server aus feststellen, ob eine bestimmte Anforderung aufgrund von Netzwerkproblemen langsam war. Dadurch bleibt die Paketerfassung erhalten, dies ist jedoch zu schwer, um in der Produktion aktiviert zu werden (1 von 10.000 Anforderungen ist möglicherweise langsam).
Jon

Darf ich als Netzwerktechniker mit mehr als 15 Jahren Erfahrung respektvoll vorschlagen, dass Sie ein clientseitiges HTTP-Dienstproblem nicht allein vom Server aus diagnostizieren können. Sie haben einfach nicht genug Informationen (was anscheinend auch Ihre Schlussfolgerung ist ... Sie scheinen jedoch nicht offen dafür zu sein, mit dieser Realität zu leben :-).
Mike Pennington

Wenn die Paketerfassung auf dem Server Netzwerkprobleme diagnostizieren kann (z. B. durch Erkennen einer langsamen TCP-Bestätigung), ist es nicht vernünftig zu erwarten, dass ein leichteres Tool / Logger dasselbe anzeigt?
Jon

0

Das Ergebnis des kb-Artikels 944884 ist, dass die tatsächliche Zeit, die zum Abschließen der Antwort erforderlich ist, möglicherweise nicht genau im Protokoll wiedergegeben wird. Aus diesem Grund wird in dem Artikel die Netzwerkzeit erwähnt.

Wenn das Symptom reproduzierbar ist, würde ich eine Paketerfassung auf der Serverseite (und vorzugsweise auch auf der Clientseite) durchführen, um die tatsächlichen Zeiten zu ermitteln, zu denen die Verbindung vom Client bestätigt wurde.


Vielen Dank, aber es ist nur durch Drosselung der Netzwerkgeschwindigkeit reproduzierbar, und eine Paketerfassung ist zu schwer, um in der Produktion verwendet zu werden.
Jon

0

Die Verzögerung von 20 Sekunden kann auch dadurch verursacht werden, dass IIS die Datei w3wp.exe neu starten muss, die in den Ruhezustand wechselt, wenn sie nicht verwendet wird.


1
Sie können diese Antwort verbessern, indem Sie auf "How to Tell" antworten. w3wp.exe schlafen gehen ist in meinem Fall nicht relevant, da ich dieses Verhalten deaktiviert habe, aber dies könnte anderen helfen.
Jon
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.