In den letzten Jahren haben wir immer wieder regelmäßig einen Performance-Sprint eingelegt, um die Performance auf den einzelnen Portalen und auch insgesamt zu messen und gegebenenfalls anschließend zu verbessern. Zusätzlich dienen uns diese Werte auch dazu, den Bedarf an Serverinfrastruktur einschätzen zu können, um uns rechtzeitig auf ein erhöhtes Aufkommen von Besucherzugriffen und Seitenzugriffen einzustellen. Dieses Jahr ist das besonders spannend, da Corona-bedingt die Zugriffszahlen sich ja in den letzten 12-15 Monaten nicht so regelmäßig und vorhersagbar entwickelt haben wie in den Jahren zuvor. Aber auf einigen Portalen sind sie in den letzten Tagen geradezu wieder explodiert. Hier wollen wir kurz die Tools und Ansätze vorstellen, die wir dabei verwenden.
Application Performance Monitoring (APM)
Mit APM messen wir die Performance der Server. Also wie lange die Bearbeitung eines Requests vom Eintreffen auf dem Server bis zum Absender der Antwort dauert. Für jedes Branchenportal sehen wir hier die häufigsten Seitenaufrufe und die durchschnittlichen Server-Bearbeitungszeiten.
Hier ein Beispiel eines Portals für die Application Performance in den letzten 24 Stunden:
Man sieht, dass hier z. B. ca. 160.000 Requests in den letzten 24 Stunden für die Suchseite stattfanden, die im Durchschnitt ca. 0,9s gedauert haben. ca. 97,8% aller Aufrufe waren schnell, ca. 2% aller Aufrufe zu langsam. Hier können wir uns gezielt langsamere Requests raussuchen und diese genauer untersuchen.
Wenn man sich den Performance-Verlauf über einen längeren Zeitraum anschaut, gibt es auch immer wieder Unregelmäßigkeiten, hinter denen Performance-Probleme stehen können. Hier ein Beispiel für die Performance im Verlauf für verschiedene Request-Typen:
Server Logs
Die klassischen Server-Logs sind immer noch sehr hilfreiche Ressourcen für Performance-Verbesserungen. Wir haben uns beispielsweise gezielt bestimmte Zeiten angeschaut, zu denen Requests langsamer werden und versucht herauszufinden, was auf den Servern in diesem Moment passiert. Dabei sind wir auf folgende Zusammenhänge gestoßen:
- Manchmal finden auf einzelnen Portalen mehrere Exporte von allen Einträgen gleichzeitig statt. Die Exporte können sich leider zeitweise blockieren und auch Datenbankabfragen von Besuchern.
- Lösung: wir werden einbauen, dass zukünftig nur noch ein Export bzw. Import gleichzeitig laufen kann.
- Auf langsamen Suchseiten, die z. B. nicht gecacht werden können wie Suchseiten von Gebieten mit unterschiedlichem Umkreisradius, werden häufig Suchanfragen im Hintergrund generiert bei Änderungen von Suchfiltern oder Arbeiten mit der Karte. Diese Suchanfragen sind teilweise unnötig, da der Benutzer mehrere Änderungen durchgeführt hat und nur am letzten Ergebnis interessiert ist.
- Lösung: Überflüssige Zwischensuchen eliminieren, so dass der Aufwand auf unseren Servern aber auch im Browser des Anwenders und im notwendigen Datenverkehr minimiert wird. Ist bereits umgesetzt.
- Außerdem konnten wir im Zusammenspiel zwischen Auswertung von Server Logs und APM-Daten sehen, dass sich einige morgendliche Hintergrund-Tasks negativ auf die Dauern von Requests auswirken. Das sind Tasks, die z. B. die Statistiken für alle Einträge berechnen, so dass bei Premium-Einträgen jederzeit die aktuelle Premium-Performance auf dem Dashboard angezeigt werden kann.
- Lösung: in den nächsten Sprints werden wir diese Tasks genauer untersuchen und so verändern, dass sie möglichst wenig Ressourcen blockieren, die für normale User-Requests benötigt werden.
Datenbank-Auswertungen
Hier erlauben uns die Analysetools zum einen, die langsamsten Datenbankabfragen anzuschauen. Auf der anderen Seite können wir auch auswerten, bei welchen Datenbanktabellen zusätzliche Such-Indexe (voraussichtlich) die Performance verbessern könnten. Nachdem die neuen Gebietssuchen mit einstellbarem Suchradius jetzt bereits mehrere Monate auf einigen Portalen laufen, halfen uns diese Daten, fehlende Indexe dort zu identifizieren und auf den Portalen einzubauen. Seitdem sind die langsamsten Anfragen deutlich schneller geworden.
User-centric performance
Neben der reinen server-seitigen Performance ist natürlich die Gesamtperformance, so wie sie ein Besucher in seinem Browser erlebt, relevant. Hier haben wir gerade begonnen, mit Hilfe von Pagespeed Insights von Google Feedback zum aktuellen Stand einzuholen und sind dabei, einige der Verbesserungsvorschläge abzuarbeiten:
- „lazy load“ für Bilder außerhalb des Viewports
- angemessene TTL (Time to live) Zeiten für statische Ressourcen
- moderne Bildformate und angepasste Bildformate über picture-Elemente
- explizite Breiten-/Höhenangaben für Bildelemente, wenn möglich
Zukünftige Performance-Messungen
Unser Ziel ist es, die Performance zukünftig regelmäßiger und häufiger zu messen, so dass wir bei Performance-Änderungen schneller eingreifen können und auch feststellen können, ob und wie sich neue Features auf die Performance auswirken. Längerfristig sollten diese Messungen natürlich automatisiert erfolgen. Dazu sammeln wir momentan noch potentielle Metriken und werden diese dann schrittweise in die vorhandenen Workflows für CI (Continuous Integration) und Deployments einbinden.
Hinterlasse eine Antwort