Anwendungs-Performance im Netzwerk

Als Netzwerker kommt man oft auch in den Genuss bei der Fehlersuche auch für Probleme im Bereich der schlechten Anwendungsleistung zuständig zu sein.

Das Netzwerk wird aus vielen Gründen für die Performance-Probleme in den unterschiedlichsten Bereichen verantwortlich gemacht.

• Für viele Anwendungen ist mittlerweile genügend Netzwerkbandbreite, auch global, verfügbar, so dass Verzögerungen und Paketverluste im Netzwerk eher zu Problemen führen als fehlende Bandbreite.
• Oft werden auf dem Weg zwischen Niederlassungen und den Rechenzentren Netzwerkkomponenten (Appliances) eingesetzt, die versuchen, die Anwendungsperformance durch Verbindungsoptimierung zu verbessern. Diese Systeme modifizieren als transparente Proxies im Netzwerk den Netzwerkverkehr für einen höheren Durchsatz und geringe Latenz.

In einer idealen Welt würde das Application Performance Management (APM) oder die anwendungsorientierte Netzwerk-Performance-Management-Lösung (AANPM) automatisch die Fehler isolieren und alle Diagnoseinformationen bereitstellen, die man für die entsprechenden Korrekturmaßnahmen benötigt. Die Realität ist jedoch viel komplexer. Interaktive Probleme, unerwartete Verhaltensweisen von Anwendungen oder Netzwerken, ineffiziente Konfigurationen oder nur der Wunsch nach konkreten Beweisen erfordern vom Administrator eine manuelle Fehlersuche.

In diesem Artikel und kommenden Beiträgen auf unserem Blog werden wir die möglichen Performance-Beschränkungen erklären, wie diese zu messen und zu quantifizieren sind, ihre Auswirkungen aufzeigen und sinnvolle Erklärungen und mögliche Wege, diese zu korrigieren, vorschlagen. Es geht darum, mögliche Leistungsprobleme zu erkennen, schneller und präziser zu beheben und gleichzeitig effektiver mit den Anwendern und den Anwendungsverantwortlichen zusammenzuarbeiten.

In diesem Artikel stellen wir die wesentlichen Anforderungen der Anwendung dar und beschreiben, wie die Analysen durch Messungen auf Paketebene durchgeführt werden.

Wir gehen davon aus, dass die Client-zu-Server-Kommunikation per Request/Reply-Mechanismus auf Basis des TCP-Transportprotokolls erfolgt. Dieses Verfahren wird bei vielen interaktiven Geschäftsanwendungen genutzt. Hierzu gehören beispielsweise webbasierte Anwendungen, Fat Client Anwendungen, Dateiserverzugriffe, Dateiübertragungen, Backups usw. Da nur das TCP-Protokoll betrachtet wird, schließt dies Voice- und Video-Anwendungen aus. Diese nutzen andere Transportmechanismen.

Für jede Operation gibt es mindestens auf der Anwendungsebene einen Request und eine entsprechende Antwort. Diese werden auch als Application Layer Protocol Data Units (PDUs) bezeichnet. Eine einfache Client-Server-Interaktion sieht wie folgt aus: Auf der Anwendungsschicht wird eine Anforderungsnachricht an den Client-TCP-Stack (TCP-Socket) zur Segmentierung (in Paketen), Adressierung und zur Übertragung übergeben. Die vom TCP-Stack erbrachten Funktionen sind in der Regel völlig transparent für die Anwendungsschicht.

Am empfangenden Ende der Verbindung (dem Server) werden die eigentlichen Anwendungsdaten aus den über das Netzwerk übermittelten Pakete extrahiert und als Applikationsschicht-Nachrichten wieder zusammengesetzt und an den zugehörigen Dienst zur Verarbeitung abgeliefert.

Sobald die interne Verarbeitung in der Anwendung abgeschlossen ist, übergibt die Serveranwendung die Antwortnachricht an den TCP-Stack des Servers. Der Nachrichteninhalt wird segmentiert und über das Netzwerk an den Client übertragen. Die Performance dieses Request/Reply-Nachrichtenaustauschs wird durch zwei Faktoren bestimmt:

• Die Verarbeitungsgeschwindigkeit der Messages am Server bzw. am Client und
• Der Zeitdauer der Nachrichtenübertragung über das Netzwerk.

Daher sollten bei einer Performance-Analyse beide Bereiche gesondert betrachtet werden. Die nach der Übermittlung wieder zusammengesetzten Informationen repräsentieren den netzwerkzentrischen Einblick in die Applikation, während die vom Allegro Network Multimeter in einer aufgezeichneten Pcap-Datei gesammelten Pakete uns darüber informieren, wie effizient das Netzwerk die Meldungen transportiert.

In der Abbildung sind beispielhaft die Messergebnisse für die Dauer der Bestätigung von Netzwerkpaketen dargestellt. Im oberen Graph ist die globale Sicht dargestellt. Sichtbar wird, dass Verzögerungen im Sekundenbereich auftreten. In der unteren Liste für einzelne Server kann man jedoch erkennen, dass hier diese Server nur Verzögerungen im niedrigen Millisekunden-Bereich haben.

Die meisten Informationen der Applikationsschicht werden in mehr als einem Datenpaket übertragen. Die Größe der Informationssegmente ist typischerweise größer als die maximale Segmentgröße MSS bzw. Nutzlastgröße die von einem Netzwerkpaket übermittelt werden kann. Diese beträgt beim Ethernet üblicherweise 1460 Byte. Die einer Anfrage oder der darauf resultierenden Antwort zugeordneten Pakete lassen sich als ein Datenfluss beschreiben. Die zusammengefasste Nutzlast aller Datenpakete eines Datenflusses repräsentiert die auf der Anwendungsebene übermittelten Nachrichten.

Abbildung 2 zeigt eine einfache Operation, die aus zwei Anfrage- und Antwortsequenzen besteht und veranschaulicht des Weiteren die zugrundeliegenden Paketflüsse auf dem Netzwerk, wobei jede Nachricht auf drei Datenpaketen aufgeteilt ist. Beim zweiten Diagramm handelt es sich um eine anwendungsbezogene Ansicht, die den reinen Nachrichtenaustausch zeigt. 

Will man die Anwendungs-Performance im Allgemeinen und die Operations-Performance im Besonderen analysieren, müssen nur die Faktoren untersucht werden, die die Übertragung der Operationsanforderung und die daraus resultierenden Antwort betreffen. Diese unterscheiden sich in den Verarbeitungszeiten der Clients und der Server und den auf der Übertragungsstrecke auftretenden Verzögerungen. Erweitert man das Flussdiagramm, dann teilt sich die Gesamtverzögerung in folgende vier Kategorien auf:

• Sendezeit des Clients beim Absenden der Nachricht,
• Verarbeitungszeit des Servers,
• Sendezeit des Servers beim Absenden der Antwort,
• Verarbeitungszeit des Clients.

Die Messung der Verarbeitungsverzögerung des Servers beginnt zu dem Zeitpunkt, an dem der Server das letzte Paket des Client-Requests empfangen hat. Dieses Paket stellt auch gleichzeitig das Ende der Request-Nachricht dar. Die Verarbeitungsverzögerung des Servers endet mit dem ersten Paket der Antwort. Dieses Paket stellt auch gleichzeitig den Anfang der Antwortnachricht (Reply) dar.

Die Messung der Sendeverzögerung beginnt mit dem ersten Paket, welches der Server als Antwort auf einen vorher eingegangenen Request übermittelt hat und endet mit dem letzten Paket der Antwortsequenz. Diese Gruppe von Paketen repräsentiert die gesamte Nachricht, die über das Netzwerk transportiert wird.

Abbildungen zeigen, wie im Allegro Network Multimeter Antwortzeiten auf Applikationsschicht bei SSL-Verkehr dargestellt wird. Auf der linken Seite werden die Zeiten für den Aufbau der Verschlüsselung angezeigt, auf der rechten Seite die Dauer der Beantwortung einer verschlüsselten Anfrage (Zeit zwischen erstem Client-Paket und erstem Server-Antwortpaket).

Die beschriebenen Messungen gehen in ein Performance-Analyse-Framework ein. Dieses Framework beschreibt neun potenzielle Leistungsengpässe zwischen den Clients, dem Netzwerk und den Servern. Daher sollten bei jeder Betrachtung der Anwendungs-Performance alle neun Problembereiche analysiert werden:

• Verarbeitungsverzögerungen der Server,
• Verarbeitungsverzögerungen der Clients,
• Bandbreitenengpässe,
• Paketverluste,
• Flusskontrolle (Zero Window),
• Geschwätzige Protokolle in Verbindung mit hohen Verzögerungen,
• Flusskontrollen auf der Anwendungsebene (Application Windowing),
• Der Nagle Algorithmus,
• Der TCP Slow-Start Algorithmus.