Wie lässt sich der Latenzunterschied zwischen einem globalen CDN und selbst betriebenen Knoten messen?

Wie lässt sich der Latenzunterschied zwischen globalem CDN und eigenen Knoten messen?

Wie groß kann der Latenzunterschied zwischen einem globalen CDN und eigenen Knoten sein? Bei internationalen Websites lässt sich diese Frage nicht anhand eines einzigen Geschwindigkeitstests beantworten. Auf derselben Website werden Produktbilder bei einem Treffer im Edge-Cache möglicherweise sehr schnell ausgeliefert, während eine Anfrage-Schnittstelle weiterhin über Kontinente hinweg auf den Ursprungsserver zugreifen muss. Ein aussagekräftiger Vergleich muss daher Regionen, Cache-Zustände und Anfragearten getrennt betrachten und anschließend die End-to-End-Latenz analysieren, statt nur Durchschnittswerte zu vergleichen.

Zunächst klären, welche beiden Verbindungswege verglichen werden

„Eigene Knoten“ kann einen einzelnen Server im Ausland oder auch einen regional gesteuerten Cluster in mehreren Regionen bezeichnen. Im ersten Fall wird beim Vergleich mit einem globalen CDN hauptsächlich die Abdeckung verglichen; im zweiten Fall müssen zusätzlich die Zusammenschaltung der Netzbetreiber, die Routing-Strategie, das Caching und der Failover betrachtet werden. Die Anzahl der Knoten lässt sich nicht direkt in eine Zugriffslatenz umrechnen. Die Nähe zum Nutzer bedeutet nicht automatisch, dass der Netzwerkpfad kürzer ist.

Vor dem Test sollten die beiden Pfade klar dargestellt werden: vom Nutzer zum CDN-Edge, vom Edge zum Ursprungsserver sowie vom Nutzer zum eigenen Knoten und vom Knoten zum Backend-Service. Wenn der eigene Knoten lediglich als Reverse Proxy fungiert und dynamische Anfragen weiterhin dieselbe entfernte Datenbank erreichen, muss der nähere Bereitstellungsort die vollständige Antwortzeit nicht zwangsläufig verkürzen.

Für einen fairen Vergleich müssen außerdem Ressourceninhalte, Komprimierung, Protokollversion und Sicherheitsrichtlinien vereinheitlicht werden. Wenn die tatsächliche Bereitstellungslösung verglichen werden soll, können die jeweiligen Optimierungskonfigurationen beibehalten werden, die Unterschiede müssen jedoch dokumentiert werden. Soll der Einfluss der Architektur ermittelt werden, sollten die Variablen möglichst kontrolliert werden. Diese beiden Testarten dürfen nicht zu einer einzigen Schlussfolgerung vermischt werden.

Die Stichprobe nach der Kundenverteilung und nicht nach der Liste der Rechenzentren planen

Bei internationalen Websites sollten vorrangig die Regionen der Werbekampagnen, die Herkunft des organischen Suchverkehrs und die Standorte qualifizierter Anfragen abgedeckt werden. Innerhalb eines Landes sollten nach Möglichkeit verschiedene Netzbetreiber sowie Festnetz- und Mobilfunknetze einbezogen werden. Cloud-Server-Sonden eignen sich für stabile Wiederholungstests, können jedoch nicht das Netzwerk echter Nutzer ersetzen. Insbesondere darf das Ergebnis eines Rechenzentrums in Europa nicht als repräsentativ für ganz Europa betrachtet werden.

Die beiden Anfragengruppen sollten in ähnlichen Zeitfenstern abwechselnd ausgeführt werden und mehrere Tage mit Geschäftszeiten und ruhigeren Zeiträumen abdecken. Dabei sind Erfassungszeitpunkt, Region, Netzbetreiber, DNS-Auflösung, tatsächlich erreichter Knoten und Protokoll zu dokumentieren. DNS-Caching und die Wiederverwendung von Verbindungen sollten ebenfalls getrennt betrachtet werden: Neue Verbindungen zeigen die Kosten des Erstzugriffs, während wiederverwendete Verbindungen eher dem Verhalten beim fortlaufenden Browsing entsprechen. Werden nur die besten Anfragen berücksichtigt, bleiben Netzwerkschwankungen verborgen.

Cache-Treffer, Cache-Fehler und dynamische Anfragen getrennt messen

Mindestens drei Objektarten sollten vorbereitet werden: cachefähige Bilder oder Skripte, Seiten, die zwischengespeichert werden dürfen, sowie nicht cachefähige Anfrage- oder Geschäfts-APIs. Bei statischen Ressourcen müssen Edge-Treffer und Cache-Fehler getrennt betrachtet werden. Es darf nicht zugelassen werden, dass das CDN einen vorgewärmten Cache verwendet, während der eigene Knoten bei jeder Anfrage den Ursprungsserver liest und der gesamte Unterschied anschließend dem Netzwerk zugeschrieben wird.

Der Cache-Status sollte anhand von Response-Headern und Plattformprotokollen bestätigt werden. Nach einem Edge-Cache-Fehler kann möglicherweise noch ein übergeordneter Cache greifen. Ein „Cache-Fehler“ bedeutet daher nicht zwangsläufig, dass vollständig auf den Ursprungsserver zugegriffen wurde. Für Tests mit kaltem Cache können kontrollierte Löschvorgänge oder separate Testobjekte verwendet werden. Das beliebige Hinzufügen von Abfrageparametern ist nicht immer wirksam, da der Cache-Schlüssel Parameter ignorieren oder dadurch der Verarbeitungspfad der Anwendung verändert werden kann.

Dynamische APIs müssen denselben Request-Body, dieselbe Authentifizierungsmethode und dieselbe Backend-Verarbeitungslogik verwenden. Mithilfe von Serverprotokollen sollten Netzwerkzeit und Ausführungszeit der Anwendung getrennt werden. Bei Tests zur Übermittlung von Anfragen sollten eine isolierte Umgebung oder Testkennzeichnungen verwendet werden, damit keine Testdaten in das System für Vertriebsleads gelangen.

Nicht nur die Zeit bis zum ersten Byte, sondern auch langsame und fehlgeschlagene Anfragen betrachten

Ping kann nur bei der Einschätzung der Netzwerk-Rundlaufzeit helfen und keinen HTTPS-Test ersetzen. Mit curl oder den Netzwerktools des Browsers können DNS-Zeit, Verbindungsaufbau, TLS, Zeit bis zum ersten Byte und Gesamtdauer erfasst werden. Zu beachten ist, dass mehrere Zeitfelder von curl die Zeit ab Beginn der Anfrage kumulativ messen und nicht direkt addiert werden dürfen. Bei der Aufschlüsselung der einzelnen Phasen müssen die Differenzen entsprechend der Definition der jeweiligen Felder berechnet und Angaben zur Wiederverwendung der Verbindung gemacht werden.

Der Bericht sollte P50, P95, Stichprobengröße und Fehlerquote nach Region, Anfrageart und Cache-Status getrennt ausweisen. P50 beschreibt das typische Nutzungserlebnis, während P95 die langsamere Gruppe von Anfragen sichtbar macht. Bei einer zu kleinen Stichprobe sollte P99 nicht überinterpretiert werden. Zeitüberschreitungen und Fehler dürfen nicht einfach entfernt werden, da eine instabile Lösung sonst schneller erscheinen könnte.

Die Latenzdifferenz kann einheitlich als „Dauer des eigenen Knotens minus CDN-Dauer“ definiert werden. Ein positiver Wert bedeutet, dass das CDN schneller ist. Gleichzeitig sollten die Originalwerte beider Seiten beibehalten werden. Das Gesamtergebnis kann nach dem Geschäftsverkehr gewichtet werden, die Details der einzelnen Regionen müssen jedoch erhalten bleiben, damit langsame Anfragen in den wichtigsten Märkten nicht durch den Durchschnitt anderer Regionen verdeckt werden.

Die Testergebnisse auf die Bereitstellung der Website übertragen

Wenn sich Nutzer und Cache-Treffer nahe am Edge befinden, kann ein CDN seine Vorteile in der Regel leichter ausspielen. Decken eigene Knoten die Kernmärkte ab und verfügen sie über eine gute Netzanbindung, kann sich der Unterschied verringern. Bei dynamischen Anfragen hängt das Ergebnis dagegen vom Pfad zum Ursprungsserver, der Wiederverwendung von Verbindungen und dem Standort des Backends ab. Eine verlässlich einheitliche Millisekundenangabe gibt es daher nicht.

Bei Plattformen wie 易营宝, die intelligente Website-Erstellung, mehrsprachige Websites, SEO und internationale Werbekampagnen miteinander verbinden, sollte die Bewertung auch reale Werbe-Landingpages und Anfragepfade abdecken. Ein schnellerer Bild-Download bedeutet nicht, dass die wesentlichen Seiteninhalte früher erscheinen. Eine Verbesserung der Zeit bis zum ersten Byte garantiert ebenfalls nicht, dass Drittanbieter-Skripte die Seite nicht weiterhin verlangsamen. Daher sollten zusätzlich Ladeindikatoren auf Browserebene erfasst und durch Real User Monitoring überprüft werden.

Vor der Abnahme sollten die Schwerpunktregionen, Cache-Regeln, Anfrageobjekte, statistischen Bewertungsmaßstäbe und akzeptablen Grenzwerte für die End-to-End-Latenz im Testplan festgehalten werden. Erst ein Bericht, der erläutert, „in welcher Region, bei welcher Anfrage und unter welchem Status eine Beschleunigung um wie viel erreicht wurde“, bietet eine ausreichende Grundlage für die Auswahl der Knoten und die anschließende Fehleranalyse.