Probleme mit der Anwendungsleistung und Latenz

Die Auswirkung der Latenz der Kommunikationsschicht wird in der Regel unterschätzt, wenn man versucht, Probleme mit der Anwendungsleistung zu beheben, aber das richtige Verständnis ist entscheidend, wenn man seine Bemühungen auf praktische Lösungen ausrichten will.

Erstens meine ich mit Latenz der Kommunikationsschicht die Zeit, die ein Paket braucht, um vom lokalen System zum entfernten System und wieder zurück zu gelangen. Der größte Faktor bei der Latenz der Kommunikationsschicht ist die Entfernung - zumindest bei geografisch getrennten Hosts. Die andere wichtige Komponente ist die Anzahl der Geräte zwischen dem lokalen und dem entfernten Host, die die Pakete verarbeiten; dazu gehören Dinge wie Router und Firewalls. Die Bandbreite der Verbindungen spielt eine Rolle, aber nicht so stark, wie die meisten Leute denken. Die Bandbreite wirkt sich auf die Einfügungsverzögerung aus - wie lange es dauert, ein Paket auf die Leitung zu bringen, aber das Signal auf der Leitung bewegt sich mit einer Geschwindigkeit, die auf dem Medium basiert, nicht auf der Bandbreite. Im weiteren Verlauf dieser Diskussion werde ich nur noch von Latenz sprechen, wenn ich die Latenz der Kommunikationsschicht meine.

Um zu demonstrieren, wie sich die Latenzzeit auf Ihre Anwendung auswirkt, nehmen wir an, Sie geben einige Daten in eine Client-Anwendung ein und drücken die Return-Taste. Die Client-Anwendung sendet eine Nachricht an eine Server-Anwendung, wartet auf eine Antwort und sendet dann eine weitere Nachricht, wartet auf eine Antwort usw., und zwar für eine bestimmte Anzahl N von "Runden". Am Ende von N Runden präsentiert die Client-Anwendung Ihnen die Ergebnisse.

Angenommen, es sind 10 Abrufe erforderlich und die Serveranwendung benötigt 1 ms, um die Client-Nachricht zu verarbeiten und eine Antwort zurückzusenden. Bei einer Latenzzeit von 1 ms ergibt sich eine Antwortzeit von 10 * (1 ms + 1 ms) oder 20 ms. Steigen Sie nun in ein Flugzeug und reisen Sie nach Chicago, der Server bleibt in Boston, so dass Sie nun eine Latenzzeit von sagen wir 50 ms und eine Antwortzeit von 10 * (50 ms + 1 ms) oder 550 ms haben. Das ist genug, um sich bemerkbar zu machen, aber nicht schmerzhaft. Erhöhen Sie die Anzahl der Umdrehungen auf 100 und Sie haben nun eine schmerzhafte Reaktionszeit von 5,5 Sekunden. Sie halten 100 Umdrehungen vielleicht für übertrieben, aber einige komplexe Datenbankabfragen oder Anwendungen, die komplexe Formulare ausfüllen, können genau das erreichen. Wissen Sie, wie viele Umdrehungen Ihre Anwendungen benötigen?
Auch bei der Ausführung einer copy_file über OSL zeigt sich dieses Verhalten. OSL sendet eine Datei in 4K-Transaktionen. Jede Transaktion erfordert eine Antwort, so dass für eine Datei mit 1.000.000 Byte 1.000.000 / 4.096 = 245 Transaktionen oder Umdrehungen erforderlich sind, um die Nomenklatur aus dem vorherigen Absatz zu verwenden. Wiederum unter der Annahme von 1 ms für die Verarbeitung der Transaktion und einer Latenzzeit von 1 ms benötigt copy_file 490 ms. Wenn wir die Latenzzeit auf 50 ms erhöhen, dauert es 12,495 Sekunden. Bei einer Vergrößerung der Datei auf 1.000.000.000 Bytes sind 244.141 Transaktionen erforderlich, mit entsprechenden Zeiten von 488,282 Sekunden bei einer Latenz von 1 ms und 12.451,191 Sekunden oder fast 3,5 Stunden bei einer Latenz von 50 ms.

Die einfachste Methode zur Messung der Latenzzeit ist der Ping.

Sie können auch ein von mir geschriebenes Programm verwenden, das die Verbindungen zeitlich erfasst, ohne dass Sie packet_monitor verwenden müssen. Siehe http://members.cox.net/ndav1/self_published/stcp_tping.doc. Der Befehl stcp_tping setzt voraus, dass Sie sich mit einem aktiven Port auf dem entfernten Host verbinden. In diesem Fall verwende ich Port 23 (telnet), aber jeder aktive Port funktioniert. Die Zahl 1 am Ende des Befehls bedeutet, dass einmal pro Sekunde eine Anfrage gesendet wird.