Protokollanalyse

Die Protokollanalyse, d.h. das Untersuchen von Datenpaketen, zählt immer noch zu den mächtigsten Instrumenten bei der Analyse von Anwendungs- Performance- und Netzproblemen. Dabei zeichnen wir den Datenverkehr an verschiedenen Stellen des Netzes auf und untersuchen die Datenpakete hinsichtlich Besonderheiten der Kommunikation. Mit dieser Art lassen sich einige Fragen klären, die sich der unmittelbaren Beobachtung durch andere Messmethoden entziehen:

Arbeiten die Netzkomponenten wie erwartet? Wurden insbesondere Standards korrekt umgesetzt oder bestehen Inkompatibilitäten zwischen Komponenten verschiedener Hersteller?

Arbeiten die Kommunikationspartner, d.h. beispielsweise die beteiligten Clients und Server, aber auch die beteiligten Software-Komponenten, wie erwartet? Auch hier kann die Übereinstimmung mit bestehenden Standards verifiziert werden.

Entspricht die gemessene Datenmenge der erwarteten? Immer wieder mussten wir feststellen, dass Anwendungen ihre Kommunikation ineffizient abwickeln und einen erheblichen „Overhead“ erzeugen, der sich letztlich negativ auf das vom Anwender beobachtete Antwortzeitverhalten auswirkt.

Ist die Kommunikation bestmöglich auf das eingesetzte Netz abgestimmt oder gibt es Defizite? Insbesondere im Bereich der Weitverkehrsnetze weisen wir regelmäßig nach, dass Kommunikationsabläufe unter den Wartezeiten auf den Leitungen leiden. Eine Verbesserung lässt sich in diesem Umfeld häufig nur durch Optimierung der Anwendungen erzielen.

Die Protokollanalyse eignet sich im besonderen Maße dazu, einen Nachweis über die Vorgänge zu führen, die für die beobachteten Effekte verantwortlich sind. Nur die tatsächlich beobachteten Datenpakete erlauben unserer Erfahrung zufolge eine konstruktive Problembearbeitung mit allen Beteiligten. Aus diesem Grunde arbeiten wir die Ergebnisse in Form verständlicher Gutachten auf und scheuen uns dabei nicht, die fraglichen Pakete und Messprotokolle darzustellen und zu erläutern. Unsere Gutachten schließen im Allgemeinen mit Empfehlungen für die weitere Vorgehensweise und die zu treffenden Maßnahmen.

Analyse von Transaktionszeiten

Als Beispiel für diese Vorgehensweise mag der folgende Trace dienen, der am Windows-Client eines Anwenders einer Außenstelle aufgezeichnet wurde. Eine bestimmte Transaktion einer Client-Server-Anwendung benötigte regelmäßig ca. 40 Sekunden, während sie bei Anwendern in der Hauptverwaltung im Allgemeinen bereits nach wenigen Sekunden abgeschlossen war. Man vermutet eine Überlastung der WAN-Strecke zur Außenstelle und erwägt, eine höhere Bandbreite beim Provider zu beauftragen.

Der Trace zeigt folgendes deutlich: Der Client (x.x.83.137) sendet Anfragen („Request“) und erhält daraufhin Antworten („Response“) vom Server (x.x.196.110). Die Antwort des Servers kommt immer nach ca. 0,01 Sekunde am Client an (Spalte „Time“, Pakete 3347, 3349, usf.). Die Antwortzeitanalyse der gesamten Transaktion ist in der folgenden Graphik dargestellt. Man erkennt, dass die Antwortzeit mindestens 0,01 Sekunden beträgt, bei einigen Vorgängen sogar bis zu 0,04 Sekunden (jeder Punkt repräsentiert eine Antwort des Servers). Die Zahl der „Ausreißer“ ist jedoch vergleichsweise gering, die meisten Punkte liegen unterhalb 0,013 Sekunden. Gleichmäßigt Antwortzeiten zeigen, dass noch Bandbreiten-Reserven vorhanden sind.

Zählt man in der Paketaufzeichnung alle Request/Response-Paare der betreffenden Transaktion zusammen, so kommt man auf 3500. Diese Zahl multipliziert mit einer Antwortzeit von 0,01 Sekunde ergibt 35 Sekunden. Eine Kontrollmessung in der Hauptverwaltung (hier nicht dargestellt) zeigt dagegen Antwortzeiten kleiner 0,001 Sekunden, die Transaktion wird hier rechnerisch mit nur 3,5 Sekunden auskommen.

Fazit: Die Arbeitsweise der Anwendung (3500 Requests/Replies für eine Transaktion) in Kombination mit der Laufzeit des WAN ist verantwortlich für die lange Transaktionsdauer. Die Laufzeit im WAN entsteht nicht auf Grund einer Überlast sondern ist in der Struktur des Weitverkehrsnetzes begründet (physische Entfernung, Zahl der Koten, usw.). Eine Leitung höherer Bandbreite wird das Problem voraussichtlich nicht beheben. Stattdessen empfehlen wir …

Das Beispiel zeigt, wie wir mit Hilfe von Protokollanalysetechniken Probleme eingrenzen und dabei den Blick auf die tatsächlichen Ursachen lenken.