Server-Timing auf allen Endpunkten

Da wir nur das verbessern können, was wir messen, haben wir begonnen, die Server-Timing-API auf allen HTTP-Endpunkten zu implementieren.

Die API bietet einfache Möglichkeiten, den HTTP-Header um einige Performance-Messwerte zu erweitern.

Für eine allgemeine Einführung in das Thema kannst du dir die Mozilla-Dokumentation dazu ansehen (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing).

Für die eigentliche Implementierung verwenden wir die folgende Rust-Implementierung, die uns Performance-Daten für den axum-Server direkt bereitstellt, (https://crates.io/crates/axum-server-timing).

Da unsere Architektur mehrere Rechenzentren umfasst, veröffentlichen wir diese Metriken nicht als eine einzige Messung. Wir haben einen geschichteten Ansatz für unser Netzwerk gewählt.

• DTZ-RED
  • Unser über das öffentliche Internet erreichbarer Endpunkt
• DTZ-BLUE
  • Internes, kundenseitiges Netzwerk
  • Die Skalierung wird in dieser Schicht gehandhabt
  • Enthält den Dienstzustand (hot/warm/cold)
• Backend service
  • Falls verfügbar, kann jeder Dienst eigene Performance-Metriken bereitstellen.
  • In unserem Fall verwenden wir die Objectstore-API

Hier sind einige Beispiel-Header, die von unserer API erzeugt werden.

server-timing: dtz-red;dur=765, dtz-blue;desc="dtz-blue(warm)";dur=538
content-length: 19276864
last-modified: Sun, 07 May 2023 10:25:33 GMT
date: Sun, 07 May 2023 10:27:52 GMT
content-type: application/octet-stream

• das Backend befand sich in einem warmen Zustand
• die blaue Schicht, Skalierung + Backend dauerten 538ms
• die rote Schicht dauerte 765ms

• das Backend war im heißen Zustand und benötigte 7ms
• die blaue Schicht dauerte 16ms
• die rote Schicht dauerte 35ms