Server Timing on all Endpoints

Puisque nous ne pouvons améliorer que ce que nous mesurons, nous avons commencé à implémenter l’API Server Timing sur tous les points de terminaison HTTP.

L’API fournit des moyens simples pour étendre l’en-tête http avec quelques mesures de performance.

Pour une introduction générale au sujet, vous pouvez consulter la documentation de Mozilla à ce sujet (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server-Timing).

En ce qui concerne l’implémentation réelle, nous utilisons l’implémentation Rust suivante, qui nous fournit des données de performance pour le serveur axum prêt à l’emploi, (https://crates.io/crates/axum-server-timing).

Comme notre architecture s’étend sur plusieurs centres de données, nous ne publions pas ces métriques comme une mesure unique. Nous avons adopté une approche en couches pour notre réseau.

• DTZ-RED
  • Notre point de terminaison exposé au public sur Internet
• DTZ-BLUE
  • Réseau interne orienté client
  • Le scaling est géré à ce niveau
  • Contient l’état du service, chaud/tiède/froid
• Service backend
  • Si disponible, n’importe quel service peut fournir ses propres métriques de performance.
  • Dans notre cas, nous utilisons l’Objectstore-API

Voici quelques en-têtes d’exemple produits par notre API.

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

• le backend était en état tiède
• couche bleue, scaling + backend a pris 538ms
• couche rouge, a pris 765ms

• le backend était en état chaud et a pris 7ms
• couche bleue, a pris 16ms
• couche rouge, a pris 35ms