© saicle/Shutterstock.com
Reimplementierung eines Onlineshops mit einer NoSQL-Datenbank in der Cloud

For Performance - Real-User-Performance


Im ersten Artikel haben wir einen grundsätzlichen Überblick über den neu zu implementierenden Onlineshop von Goodgame Studios gegeben. Der zweite Artikel fokussierte auf den Umgang mit großen Datenmengen und NoSQL-Datenbanken. Im dritten Artikel sind wir auf die Architektur und weitere besondere Bedingungen eingegangen, die zu beachten sind, wenn man Software für den Einsatz in der Cloud schreibt. In diesem Artikel widmen wir uns den verschiedenen Facetten der Webperformance.

Der Artikel ist dafür wie folgt aufgebaut: Zuerst beschreiben wir das Setting und die Herausforderung an unsere Performance. Daran anschließend gehen wir näher auf die technischen Rahmenbedingungen rund um Performance ein (wie beispielsweise Technologien etc.). Danach zeigen wir das Zusammenspiel.

Das Setting

Mehr als 220 Mio. Nutzer greifen aus 230 Ländern (Google Analytics) auf unsere Systeme zu. Eine schnelle, weltweite Verfügbarkeit ist daher unsere primäre Anforderung. Genauer gesagt möchten wir mit unseren Systemen innerhalb weniger Millisekunden für die Kunden nutzbar sein, um ein optimales Spielerlebnis zu gewährleisten. Für diesen Anspruch im Bereich Performance müssen eine Reihe von Frontend-Technologien richtig verstanden und eingesetzt werden.

28 Mio. Spieler kaufen in diesem Onlineshop Produkte. Insbesondere zu Rabattaktionen bedeutet das eine große Anzahl von Seitenabrufen. Der Shop muss in dieser Situation zuverlässig und performant reagieren.

Die Herausforderung

Unsere Herausforderung ist es, weltweit eine hohe Performance zu erreichen. Unser Ziel ist die vollständige visuelle Darstellung unterhalb von 2 000 ms. In Ländern mit guter Internet­infrastruktur gehen wir noch deutlich anspruchsvoller heran. Dabei sind wir in dem Spannungsfeld, dass wir möglichst viele visuelle Mittel nutzen (Grafiken, Animationen etc.) und gleichzeitig eine hohe Performance erzielen wollen. Ein tiefes Verständnis der Browsertechnologien und der Internet­infrastruktur ist dafür unerlässlich.

Was bedeutet Performance für uns?

Unsere Zielsetzung ist es, dem Nutzer möglichst schnell eine Webseite anzuzeigen. Darunter verstehen wir den Zeitpunkt, an dem die Seite visuell komplett ist und der Nutzer interagieren kann. In vielen Unternehmen wird noch immer der onLoad-Event genutzt, um zu sehen, wie schnell eine Webseite lädt. In vielen Anwendungsfällen ist es üblich, Third-Party-Tools wie z. B. Google Analytics etc. einzubinden. Der Nutzer bekommt davon normalerweise nichts mit, da es im Hintergrund passiert, nachdem der visuelle Teil der Seite geladen wurde. Aber auch diese Zeit wird dem onLoad hinzugezählt; daher halten wir diesen Wert für ungünstig. Wir versuchen einen Wert zu bekommen, der die Seite „visuell komplett“ abdeckt („Visual Completeness“). So können wir uns darauf konzentrieren, den Seitenladewert bis zu genau diesem Zeitpunkt zu optimieren, um dem Nutzer ein noch besseres Erlebnis zu bieten

Wie messen wir?

Es gibt viele Möglichkeiten und Punkte, an denen man ansetzen kann, die Performance zu messen. Da für uns die Performance aus Sicht des Endanwenders am wichtigsten ist, versuchen wir die realen Ladezeiten der Nutzer zu bekommen. Sei es aus einem Highspeednetzwerk oder aus strukturschwachen Gegenden mit kleiner Datenübertragungsrate. Das geschieht über das so genannte Real User Monitoring (RUM).

Das ist aber nur ein Aspekt. Um zu gewährleisten, dass wir eine Verfügbarkeit und End-to-End-Performance aller Browser über alle Standorte des Unternehmens haben, nutzen wir ergänzend das synthetische Monitoring. So können wir das Beste aus beiden Welten nutzen und haben eine komplette Abdeckung.

Real User Monitoring

Unser Ziel sind Performancemessungen aus Anwendersicht. Wir erreichen das durch passive Beobachtung der von „echten“ Anwendern durchgeführten Transaktionen. Wir möchten also keine Daten aus Rechenzentren nutzen, bei denen eventuell der Rechner, der die Messungen ausführt, direkt neben dem steht, der die Ressource ausliefert.

Jeder aktuelle Browser liefert bereits eine Menge an Messwerten für Ladezeiten automatisch mit. Das geschieht über ein definiertes JavaScript-API. Öffnet man die Entwicklertools eines Browsers und gibt window.performance.timing in die Konsole ein, bekommt man ein Objekt zurückgeliefert, in dem diese Werte geliefert werden (Abb. 1). In diesen Werten ist alles von der ersten Interaktion des Nutzers, also der Anfrage der Seite, bis hin zum kompletten Laden enthalten.

bleek_case-study_1.tif_fmt1.jpgAbb. 1: „window.performance.timing“-Objekt (Bildquelle [1])

Hier kann man sich seine Werte berechnen, je nachdem, wie sie benötigt werden. Sei es die Überwachung der Netzwerkzeit oder die Zeit, die gebraucht wird, um den DOM aufzubauen.

Bei der Bemessung von einer „Visual Completeness“ wird es etwas schwerer. Hierzu gibt es noch die Möglichkeit, mit dem Resource Timing zu arbeiten. Aufgebaut ist es wie das Navigation Timing, nur besteht hier die Möglichkeit zu messen, wie lange eine einzelne Ressource gebraucht hat, bis sie geladen wurde. Ein Wert, der hier zurückgeliefert wird, ist „Duration“. Dieser beinhaltet nicht alleine die Zeit, die gebraucht wurde, bis das Asset geladen wurde, sondern auch noch mögliche Wartezeiten im Netz. Hier können wir jetzt die Werte aller Assets anfordern und den größten Wert speichern. Wenn wir uns diesen Wert nun mit dem Wert für eine ermittelte „Time To First Byte“ aus dem Navigation Timing zusammenzählen, haben wir einen annähernden Wert für „Visual Completeness“. Dabei kann man wählen, wie man die Assets auswählen möchte. Das geht über den direkten Pfad mit performance.getEntriesBy("Pfad") oder mit performance.getEntriesByType("resource") für alle Ressourcen, die man so laden kann.

Einziger Nachteil an dieser Methode ist, dass das Resource Timing noch nicht im Safari unterstützt wird. Mehr Informationen zum Resource Timing Model (Abb. 2) (engl.) findet man unter [2].

bleek_case-study_2.tif_fmt1.jpgAbb. 2: Resource Timing Model, Bildquelle: [3]

Synthetisches Monitoring

Während man beim Real User Monitoring auf die Interaktion des Nutzers warten muss, wird beim synthetischen Monitoring der User simuliert. Synthetisches Monitoring wird von einigen Firmen wie z. B. Compuware oder Catchpoint angeboten. Der Vorteil liegt bei der fortlaufenden Überwachung der Antwortzeit, Verfügbarkeit und End-to-End-Performance aller Browser über alle Standorte des Unternehmens. Durch regelmäßig eingestellte Tests haben wir sofort eine Übersicht, ob etwas fehlschlägt oder sich anormal verhält. Zur Sicherheit können wir dies dann noch einmal mit den RUM-Ergebnissen vergleichen. Der Nachteil ist natürlich, dass der User nur simuliert wird. Wenn der Rechner, der den User simuliert, und der Server, auf dem unsere Webseite liegt, in einem Rechenzentrum stehen, sind die Ergebnisse geschönt.

Die Webseite wird geladen

Unser Onlineshop besteht aus Webseiten. Jede Webseite besteht aus einer Reihe von Elementen. Das erste Element ist immer die HTML-Datei, die den Aufbau der Seite beschreibt. Sie verweist auf eine Reihe weiterer Elemente: Grafikelemente, Audioelemente usw., die man Assets nennt. Daneben gibt es die Möglichkeit, JavaScript-Dateien und Cascad­ing Style Sheets usw. zu referenzieren; auch das sind Dateien, die nachgeladen werden. Sobald genügend Informationen vorliegen, fängt der Webbrowser an, die Seite darzustellen. Einige Informationen können dann noch zu einer veränderten Darstellung der Seite führen, sodass der Browser ggf. Dinge, die schon gezeichnet sind, noch einmal neu darstellen muss.

Unser Ziel bei der Performanceoptimierung ist es, diesen Ladevorgang und alle Zeichenoperationen des Webbrowsers auf das beste Verhältnis zu optimieren. Im Folgenden beschreiben wir, worauf man dabei achten muss.

Was müssen wir uns zuerst anschauen

Wenn wir uns die Auswertung des HTTP-Archivs ansehen, wird kla...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang