End2End Probleme

Auf den ersten Blick scheinen End2End ein geniales Werkzeug zur Analyse von Netzwerkproblemen zu sein. Allerdings funktionieren nicht alle Tests in allen Fällen problemlos. Hier ein paar Beispiele

MAPI Cache

Schon bei einem meiner ersten End2End-Checks bin ich die die Falle gelaufen. Ein Benutzer beschwerte sich zu Exchange 2000/2003-Zeiten über eine schlechte Postfach-Performance. Ich habe dann per CDO und MAPI per VBScript jede Sekunde die Mail in seinem Postfach gelesen und die Zeit gemessen. Leider war die Messung komplett ohne Befund und alles was schnell.

In der ganzen Zeit hat aber auch der Anwender sich nicht über eine schlechte Performance beschwert. Sollte ich wirklich einen Zeitraum erwischt haben, in dem alles OK war?.

Ich habe die Messung abgeschaltet und kurz darauf hat sich der Anwender wieder beschwert. Im Blindversuch habe ich dann das Prüf-Skript ohne wissen des Anwender Tageweise eingeschaltet und ausgeschaltet. Fast genau im gleichen Takt hat sich der Anwender beschwert oder nicht beschwert.

Ich konnte mir damals das Verhalten nur so erklären, dass der Exchange Server etwas knapp an Speicher war. Solange ich die Mailbox immer wieder gelesen habe, hat Exchange auch die Informationen im RAM vorgehalten und der Benutzer selbst konnte auch schnell darauf zugreifen. Wenn ich aber nicht mehr gemessen habe, dann war das Postfach eines unter vielen und natürlich gab es dann Situationen, in denen Exchange die Mails erst von der Festplatte nachladen musste. Damals war ja alles noch 32bit und die Hauptspeicherausstattung auf wenige GB beschränkt.

Netzwerk-Cache und WAN-Optimierer

Eine andere Komponente kommt bei Tests per HTTP ins Spiel. Gerade Firmen nutzen gerne HTTP-Proxy-Server da diese auch eine Authentifizierung, URL/Malware-Filterung und Abrechnung erlauben. Wenn der Proxy-Server die Dateien natürlich schon hat, dann kann er diese auf lokalen Festplatten vorhalten und anderen Anwendern mit der gleichen Anforderung direkt zurück liefern. Das funktioniert wunderbar für statische Inhalte wie Bilder, Icons, CSS-Stylesheets oder JavaScript-Code, der in eigenen Dateien ausgelagert ist.

Wenn ich nun z.B. mit End2End-HTTP immer wieder die gleiche statische URL abfrage, dann ist es sehr wahrscheinlich, dass ein Proxy-Server diese Abfrage wiedererkennt und den Inhalt einfach lokal ausliefert. Die Latenzzeit ist dann natürlich deutlich kürzer.

In letzter Zeit kommen auch immer mehr "Cloud Proxy Server" sind Spiel, bei denen der Kunde die Dienstleistung des "Filter" extern abgibt. Die Clients machen dann einen Umweg über den Proxy in der Cloud, was die Latenzzeit je nach Anbindung vergrößert oder verkürzt.

Das gleiche Thema gilt auch für WAN-Optimierer wie z.B. Riverbed, die unterschiedlichste Protokolle optimieren. Sie fassen Pakete zusammen, komprimieren diese und verhindern redundante Übertragungen. Die Bandbreite wird geschont und andere Dienste passen auch noch durch. Je nach Umgebung wird meine Latenzzeit aber höher, da diese zusätzliche Verarbeitung und Gruppierung zusätzlich Zeit dauert. Auf der anderen Seite kann die Latenz niedriger werden, wenn das lokale System die Daten aus seinem Cache ausliefert.

Bei HTTP gibt es die Möglichkeit über den HTTP-Header den Wunsch mitzuliefern, dass die Daten nicht aus einem Cache kommen.

@{"Cache-Control"="no-cache"}

Ich nutzen den Header in End2End-HTTP aber kann natürlich nicht sicher sein, dass alle Zwischenstationen meinen Wunsch befolgen. Messwerte sollten sie also kritisch hinterfragen.

TLS-Handshake

Je nach Test sollten sie auch den TLS-Handshake im Blick habe. Wenn Sie die erste Verbindung aufbauen, bei der Zertifikate zum Einsatz kommen, dann ist schon der Verbindungsaufbau aufwändiger und die Prüfung der Zertifikate kann auch noch extra Zeit in Anspruch nehmen.

Wenn Sie aber ihren Test so auslegen, dass die einmal aufgebaute Verbindung wieder genutzt wird, dann müssen Sie einfach den ersten Test überspringen oder gleich wiederholen. Bei Performance-Messungen wird diese Startphase auch als "WarmUp" bezeichnet. Für andere Tests gibt es sogar noch eine "CoolDown"-Phase. Das ist z.B. beim Messen von Dauerleistung bei Festplatten erforderlich, die am Anfang durch den internen Cache besonders schnell sind und die Messung verfälschen.

IDS/DoS Schutz

Beachten Sie bei ihren Tests auch die Gegenseite. Dies gilt insbesondere, wenn ihnen die Gegenseite nicht gehört. Speziell Dauertests werden nicht von allen Gegenstellen freundlich aufgenommen und können durchaus erkannt werden. Es gehört zu jedem guten "Intrusion Detection System" und jeder "DDoS-Abwehr" entsprechend ungewöhnliche Zugriffsmuster zu erkennen und möglichst früh zu unterbinden. Die Reaktion darauf fällt sehr unterschiedlich aus. Die Verbindung kann mit einer Fehlermeldung werden, das andere System stellt sich Tod u.a.

Wenn Sie Google zu stark nerven, dann können ihre Anwender z.B. folgende Meldung zu Gesicht bekommen.

Das kann insbesondere zu Rückfragen von Anwendern führen, die sich zurecht keiner Schuld bewusst sind. Da ihre Tests aus dem Firmennetzwerk aber vielleicht die gleiche externe IP-Adresse nutzen, kann die andere Seite dies nicht unterscheiden.

Auch Microsoft versucht solche Muster zu erkennen und blockt eventuell den Zugriff.


https://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx 22.6.2020 von meinem T-DSL-Anschluss aber auch per Tor

Das stört zwar z.B. die Messung per End2End-HTTP nicht wirklich aber natürlich alle anderen "legitimen" Zugriffe von Anwendern

IDS und DDoS-Schutz gibt es aber nicht nur in der Cloud oder der Gegenstelle, sondern kann auch in ihrem lokalen Netzwerk die Messung verfälschen oder blockieren. Das ist dann aber eine interne Angelegenheit. Denken Sie dabei auch an Port-Limits. Wenn Sie für jeden Test eine eigene TCP-Connection starten und viele Tests pro Minute laufen, dann könnten auch ihre verfügbaren TCP-Ports irgendwann zur Neige gehen

Weitere Links