Browser-, API- und Datenbankzeiten richtig zuordnen

Ein langsamer Bildschirm zeigt noch nicht, an welcher Stelle die Zeit verloren geht. Für eine gezielte Untersuchung brauchen Entwicklung und Betrieb dieselbe Aufgabe, dieselbe Anfrage und klar benannte Messgrenzen.

Das folgende Beispiel ist vollständig hypothetisch. Die Kennung req-17, alle Zeiten und die Abfragestruktur sind erfunden. Es wurde kein Kundensystem gemessen.

Einen konkreten Aufruf abgrenzen

Im Beispiel lädt ein Portal eine Bestellliste mit 20 Zeilen. Zur Anfrage gehören diese angenommenen Messwerte:

Die Datenbankzeit liegt innerhalb der Serverzeit, diese wiederum innerhalb des Ressourcenabrufs. Wer die Werte addiert, zählt enthaltene Zeit mehrfach. Bei parallelen Aufrufen kann zudem ihre aufsummierte Dauer größer sein als die verstrichene Zeit.

Absolute Startzeiten von Browser und Server lassen sich ohne passende Zeitbasis nicht einfach voneinander abziehen. Verwenden Sie definierte Dauern und eine nachvollziehbare Zuordnung zur selben Anfrage.

Die auffällige Stelle genauer untersuchen

Im erfundenen Ablauf entstehen 21 Datenbankaufrufe: eine Listenabfrage und danach je eine Detailabfrage pro Zeile. Das macht den wiederholten Datenzugriff zu einem konkreten Prüfpunkt. Eine hohe Abfragezahl allein würde diesen Aufbau noch nicht beweisen; hier ist er Teil des Beispiels.

Untersuchen Sie, welche Informationen die Ansicht tatsächlich benötigt. Ein begrenzter gemeinsamer Abruf kann eine mögliche Änderung sein. Er muss dieselben erlaubten Datensätze liefern. Alle Daten vorsorglich in eine riesige Abfrage zu packen, folgt daraus nicht.

Der Browserwert in der Tabelle endet beim Empfang der Ressource. Er belegt nicht, dass die Ansicht dann bedienbar ist. Bleibt sie anschließend blockiert, müssen Verarbeitung, Darstellung und weitere Ressourcen gesondert betrachtet werden.

Eine Änderung unter vergleichbaren Bedingungen prüfen

Notieren Sie Softwarestand, Aufgabe, Datenmenge und Filter sowie den Berechtigungsbereich. Gleichzeitige Last und der Zustand des Caches gehören ebenfalls dazu. Ein leerer Cache und ein bereits gefüllter können unterschiedliche Ergebnisse liefern.

Wiederholen Sie den relevanten Ablauf vor und nach der Änderung unter passenden Bedingungen. Prüfen Sie neben der Zeit auch, ob Ergebnis und Zugriffsgrenzen stimmen. Ein einzelner besonders schneller Aufruf reicht nicht als allgemeiner Verbesserungsnachweis.

Technische Messwerte sollten gezielt zugänglich sein; Kundeninhalte werden für diese Notiz nicht benötigt. Das Ergebnis der Untersuchung ist eine begründete nächste Änderung mit benanntem Umfang, kein pauschales Urteil über die Geschwindigkeit der gesamten Anwendung.

Quellen

• MDN — Server timing

• MDN — PerformanceResourceTiming: responseEnd

• Microsoft — Chatty I/O antipattern