Endnutzer besser verstehen durch Performance-Monitoring

Mit einem ständigen Auge auf Qualität überwachen wir die Performance unseres Content Delivery Networks (CDN), und das an möglichst vielen Standorten und bei möglichst vielen Netzwerkprovidern weltweit. Performance-Monitoring ist unerlässlich – nicht nur, um Server und Netzwerktechnik in Schuss zu halten, sondern auch, um die User Experience der Endnutzer nachempfinden zu können.

Für das Performance-Monitoring stehen uns diverse Tools zur Verfügung. In diesem Blogpost geht es speziell um Catchpoint. Die grundsätzlichen Aussagen gelten jedoch für alle Anbieter von Tools zum externen Performance-Monitoring (Third-party Performance Monitoring, TPM).

Warum Sie die Performance messen sollten

Performance ist für nahezu jeden Wirtschaftszweig mit Webpräsenz von entscheidender Bedeutung. Die Art und Weise, wie Ihre Endnutzer die Interaktion mit Ihrer Website oder mobilen App erleben, wirkt sich unmittelbar auf Conversion und Nutzerzufriedenheit aus. Ein gutes Beispiel dafür ist das Marissa Mayer Google Experiment: Mayer erhöhte die Anzahl der Google Suchergebnisse auf 30. Daraufhin gingen Traffic und Umsatz von Google um 20 % zurück. Wie kam es zu diesem Rückgang, zumal Nutzer ausdrücklich nach mehr Ergebnissen verlangten? Bei ihrer Recherche fand Mayer heraus, dass mehr Ergebnisse auch eine Verlängerung der Seitenladezeiten von 0,4 Sekunden auf 0,9 Sekunden zur Folge hatten – eine Verzögerung von einer halben Sekunde führte zu 20 % weniger Traffic und geradewegs zu unzufriedenen Nutzern.

Fazit ist, dass Nutzer großen Wert auf Performance legen. Daher sollten Sie die Performance stets im Blick behalten.

Monitoring: „Verfügbarkeit“ oder „Performance“?

Um gewährleisten zu können, dass Ihre Infrastruktur reibungslos funktioniert, ist das Monitoring der Verfügbarkeit unerlässlich. Aber leider lässt die Verfügbarkeit keinerlei Schlüsse auf die User Experience Ihrer Endnutzer zu.

Durch Monitoring der Verfügbarkeit Ihrer Infrastruktur stellen Sie sicher, dass ausreichende Storage-Kapazitäten vorhanden sind, Netzwerk-Ports nicht überlaufen, Server nicht überlastet werden und alle Bestandteile der Infrastruktur fehlerfrei funktionieren. Sie konzentrieren sich ausschließlich auf Kennzahlen zur Infrastruktur und bewerten mit „Entweder/Oder“: der Server funktioniert oder nicht, der Server braucht mehr RAM oder nicht, Sie müssen bei Ihrem ISP einen neuen Netzwerk-Port hinzubuchen oder nicht usw. Eine Auswertung dieser Kennzahlen, ohne Blick über den Tellerrand hinaus, ergibt ein recht kurzsichtiges Bild auf die IT-Umgebung. Es fehlen Messwerte zu synthetischen oder realen Nutzern. Zudem wird das Monitoring der Verfügbarkeit allzu oft lediglich zum Reagieren auf akute Situationen genutzt (z. B. bei Ausfall von Komponenten). Einblicke in den Betriebsverlauf und Reporting-Tools fehlen meist.

Performance-Monitoring hingegen bildet nach, was der Nutzer tatsächlich erlebt, und ergibt daher ein deutlicheres Bild des Verhaltens von Nutzern und Browsern bzw. Anwendungen. Das Monitoring der Verfügbarkeit erlaubt, wie eben schon erwähnt, lediglich Einblicke in interne Abläufe, während ein Monitoring der Performance einen genauen Überblick über die vielfältige Basis an synthetischen und realen Nutzern und ihrer Browser und somit ein viel umfassenderes Bild liefert. Zudem können Sie wertvolle Erkenntnisse zum Dialogverhalten Ihrer Nutzer gewinnen und Verlaufstrends auswerten. Das gibt Ihnen die Möglichkeit, die Weiterentwicklung und Anpassung an sich ändernde Gegebenheiten erfolgreich zu gestalten.

So sorgen Monitoring-Tools externer Anbieter für Transparenz

TPM-Tools verschaffen Ihnen ein Bild über Ihre Nutzer weltweit, Diversität und geografische Verteilung inbegriffen, die Möglichkeit komplexer Abfragen über Daten hinweg, Einsichten in die Art und Weise der Ausführung der einzelnen Dialogschritte und die Möglichkeit zum Emulieren vieler Typen von Endpoints – und all dies können Sie mit Ihren im eigenen Hause gewonnenen Daten verknüpfen.

Zudem liefern Ihnen diese Tools die historischen Daten, die Sie zum Einordnen wichtiger Ereignisse (z. B. ein neues Release Ihrer Software) benötigen, und möglicherweise sogar Einblicke in die Abläufe Ihrer IT-Umgebung auf App-Ebene. Mit TPMs können Sie zielführende A/B-Test vornehmen und Ihre Anbieter und Geschäftspartner im Blick behalten. So könnte es z. B. sein, dass einige Ihrer auf Ihrer Homepage eingebetteten Geschäftspartner nicht immer ausreichend Kapazitäten einplanen und somit nicht allzu viel Wert auf die Performance Ihrer Website legen.

Tatsache ist, dass Fastly alle seine Kunden zur Nachverfolgung der Performance ihrer Fastly Produkte ermuntert – Sie sollten unbedingt wissen, wie sich alle Ihre Services schlagen, insbesondere Ihr CDN.

Diese wichtigen Kennzahlen sollten Sie berücksichtigen

Hier einige der wesentlichen Kennzahlen, denen Sie besonderes Augenmerk schenken sollten:

• DNS-Lookup: Am Anfang nahezu aller Aktivitäten im Web steht ein Domaine Name System (DNS). Im Fall eines Fastly Kunden führt der Test-Agent von seinem Upstream-Resolver aus einen DNS-Lookup aus, und der Resolver gibt, in Abhängigkeit von der Konstellation zwischen dem Kunden und Fastly, einen CNAME Record oder einen A Record zurück. Typischerweise erhält der Kunde einen oder mehrere A Records von Fastly. Im Idealfall geht dieser Request bei einem geografisch nahegelegenen Server des autoritativen DNS-Providers ein (der Fastly Autoritativ ist „Dyn“), und dieser DNS-Server gibt dem anfragenden Client die IP-Adresse des am nächsten gelegenen Servers zurück. Nutzen Sie einen externen autoritativen DNS-Provider (hoffentlich nutzen alle Fastly Kunden NSOne, Dyn, Verisign usw.), liegt die Verantwortung für Probleme und Verbesserungen hauptsächlich bei diesem Provider. Behalten Sie also Ihren Provider im Auge. Sollten Sie eigene autoritative DNS-Server unterhalten, ist es ratsam, diese Server auf der ganzen Welt zu verteilen und sich mit dem Betreiben eines Anycast Netzwerks zu befassen (keine einfache Sache). Ein Problem in diesem Zusammenhang ist, inwieweit DNS-Zeiten in Tools von Drittanbietern gegenüber der realen Welt „überbewertet“ werden, aber mehr dazu in einem späteren Blogpost.

• Connect: Das ist im Grunde genommen der End-to-End-Aufbau einer Netzwerksitzung und einer anfänglichen TCP-Sitzung (SYN<>ACK<>SYN/ACK). Mit dem Abrufen des Root-Objekts einer Webseite – der primären URL von www.ihresite.com – bauen Sie eine einzelne Verbindung auf und das ergibt die Verbindungszeit. Beim Testen einer prall gefüllten Webseite stellen die meisten Browser sechs parallel genutzte Verbindungen her. Es gilt also darauf zu achten, was die Kennzahl im Bericht des Testanbieters bedeutet und worauf sich diese Kennzahl bezieht. Diese Kennzahl wird im Wesentlichen durch die Roundtrip-Latenz (die dominante Eingangsgröße) bestimmt. Hinzu kommen sämtliche Penalties durch gegebenenfalls überlastete Hardwarekomponenten. Diese Kennzahl können Sie stets durch eine günstigere Verteilung der Infrastruktur verbessern, sowohl geografisch (dieser Aspekt wird primär durch Inbetriebnahme neuer Standorte abgehandelt) als auch physisch (durch Hinzufügen von Servern/Loadbalancern, falls diese bezüglich TCP-Verbindungen an ihre Grenzen kommen).

• TLS-Handshake: Viele Websites stellen vollständig auf Transport Layer Security (TLS) um. Google hat damit begonnen, Sites, die sichere HTTPS-Verbindungen verwenden, ein höheres Ranking zu geben. Achten Sie darauf, wie lange der Aufbau des TLS-Handshakes dauert – TLS-Handshakes können mehrere Roundtrips verursachen, die wesentlich zu den Seitenladezeiten beitragen. Es ist daher wichtig, dass sich der TLS-Kommunikationspartner so nah wie möglich am Nutzer befindet (z. B. durch Nutzung eines CDN). Stellen Sie sicher, dass Ihr TSL-Stack (bzw. der TSL-Stack Ihres Providers) optimiert wurde. Im Fall eines externen Providers (CDN, ELB) als TSL-Kommunikationspartner behalten Sie diesen im Auge, damit sowohl Performance als auch Sicherheit garantiert sind.

• WAIT oder First Byte: Sobald die Verbindung steht, läuft die Zeit „WAIT“, also die Zeit bis zum Empfang des ersten Bytes der Antwort von der primären URL. Sie können sich das einfach als die für den Verbindungsaufbau benötigte Zeit plus Datenträger-Penalties bis zum Eintreffen des ersten Datenbytes beim Client vorstellen. Sollten keinerlei Verzögerungen aufgrund zusätzlich benötigter Rechenzeit auftreten (z. B. Zeit für das Abrufen des Images von Festplatte oder aus dem RAM), ist dieser Wert gleich der Zeit für den Verbindungsaufbau. Es leuchtet ein, dass die WAIT-Zeit niemals kürzer sein kann als die Zeit für den Verbindungsaufbau. Bei einer sauber ausgelegten und sachgemäß skalierten Architektur wird im Mittel ein Delta von weniger als zwei Millisekunden erreicht. Hier noch eine Vorwarnung an CDN-Nutzer: Bei Pass-Through (also ohne Ablegen von Content in Zwischenspeichern, das CDN muss den Content direkt vom Origin-Server abrufen) weicht WAIT beachtlich von der für den Verbindungsaufbau benötigten Zeit ab.

• Content-Download oder LOAD: Das ist die Zeit vom Laden des ersten Bytes bis zum Laden des letzten Bytes von der zu testenden URL. Dieser Wert ist im Wesentlichen eine Funktion von Bandbreite, Latenzzeit und Funktionstüchtigkeit der Algorithmen zur Steuerung des TCP-Datenflusses zwischen Client und Server. Diese Zeit kann durch allerlei Kniffe auf Betriebssystemebene verkürzt werden. Den größten Gewinn erreichen Sie jedoch, indem Sie einfach weniger Daten senden. Komprimieren Sie also so viel wie möglich. gzip-Komprimierung beispielsweise ist für alle zeitgemäßen Browser geeignet. Sie können diese Komprimierung sowohl auf Ihrem Webserver oder Loadbalancer oder, falls Sie ein CDN nutzen, auch in Ihrem CDN einrichten.

Unten sehen Sie ein Catchpoint Performance Chart. (Zur Erinnerung: Wir verwenden meist die Terminologie von Catchpoint. Es gibt zahlreiche Tools dieser Art, die möglicherweise andere Begriffe für dieselben Komponenten verwenden.) Dieses Diagramm zeigt die Performance ein und desselben Objekts bei Abruf über ein CDN und bei direktem Abruf vom Origin-Server. Sie sehen die fünf soeben besprochenen Komponenten. Die Summe aller dieser Einzelkomponenten zusammen ergeben die „Webpage Response (ms)“.

Nächste Schritte

Ein guter Anfang wäre, wenn Sie einen Test für Ihre Website ausführen und sich auf Web Page Test den Optimierungsscore anschauen. Recherchieren Sie mehrere TPM-Anbieter. (Wir bevorzugen Catchpoint, es gibt aber auch noch andere.) Bringen Sie genau in Erfahrung, auf welche Art und Weise Ihr Anbieter die Performance testet, und scheuen Sie sich nicht, Zeit und Geld in diese Angelegenheit zu investieren. Sparen Sie nicht am falschen Ende.

Das Monitoring der Performance ist, wie ich hoffentlich aufzeigen konnte, zur besseren Veranschaulichung Ihrer Endnutzer unerlässlich – nutzen Sie die gewonnenen Daten, um entscheidende Metriken im Blick zu behalten und Verbesserungen voranzubringen.