Performance

Le bext est livré avec un système intégré de mesure des performances et de prévention de la régression. Chaque PR est comparé, chaque mesure dispose d'un budget et les régressions sont détectées avant d'atteindre la production.

Cadre budgétaire#

Les sites déclarent [perf.budget] dans bext.config.toml pour définir des seuils par métrique. Lorsqu'une exécution de charge de travail dépasse un budget, la porte de régression fait échouer la construction.

toml

[perf.budget]
p50_ms = 8
p99_ms = 25
rss_mb = 128

[perf.budget.features]
waf = { p50_add_ms = 1.5 }
compression = { p50_add_ms = 0.5 }

Les budgets sont appliqués par charge de travail. Si une charge de travail ne déclare pas de budget pour une métrique, le budget global s'applique.

Magasin d'histoire#

bext bench history <workload> affiche la chronologie d’une métrique à travers les validations. Le magasin d'historique conserve les résultats dans .bext/bench-history/ par défaut, avec un téléchargement S3 en option pour une visibilité à l'échelle de l'équipe.

code

$ bext bench history blog_read_heavy --metric p99_ms --last 20
commit    date        p99_ms
a1b2c3d   2026-04-01  12.3
d4e5f6g   2026-04-02  12.1
h7i8j9k   2026-04-03  14.8  << regression
...

Utilisez bext bench blame <workload> --metric p99_ms pour identifier la validation qui a introduit une régression à l'aide d'une recherche binaire dans l'historique.

Porte de régression#

CI exécute perf-gate sur chaque PR. La porte compare les résultats de la charge de travail du PR à la ligne de base de la branche principale et échoue si une métrique régresse au-delà de la bande MAD (écart médian absolu).

La porte utilise un modèle statistique plutôt qu'un seuil fixe afin que la variance naturelle ne provoque pas de faux positifs. Une régression doit dépasser 2 fois le MAD des 10 dernières exécutions de référence pour déclencher un échec ( MAD_MULTIPLIER = 2.0 dans bext-bench-history/src/band.rs ).

code

$ perf-gate --baseline main --compare HEAD
PASS  blog_read_heavy      p50_ms   7.8 vs 8.1  (+3.8%, within 2x MAD)
FAIL  ssr_dynamic           p99_ms  22.1 vs 18.4 (+20.1%, exceeds 2x MAD of 1.2)

Coût par fonctionnalité#

bext bench cost affiche le tableau des coûts : combien chaque fonctionnalité compilée ajoute aux métriques clés. Ceci est mesuré en créant avec et sans chaque fonctionnalité et en différenciant les résultats de la charge de travail.

code

$ bext bench cost
feature           p50_add_ms   rss_add_mb   binary_add_kb
waf               +1.2         +3.4         +820
tls               +0.1         +1.8         +1200
react-compiler    +0.0         +0.5         +340
v8                +0.3         +12.1        +4800

Interpréter les échecs#

Lorsque la porte échoue, l'erreur affiche :

Quelle charge de travail a régressé (par exemple ssr_dynamic ).
Quelle métrique a dépassé la bande (par exemple p99_ms ).
Le delta entre le PR et la ligne de base, exprimé à la fois sous forme de valeur absolue et un pourcentage.
La bande MAD afin que vous puissiez voir à quelle distance en dehors de la variance normale la le résultat tombe.

Causes courantes de régressions :

Ajout d'une opération synchrone au hot path de la demande.
Une mise à jour de dépendance qui augmente la taille binaire ou le temps de démarrage.
Un changement de configuration du cache qui réduit les taux de réussite.
Un clone() accidentel ou une allocation dans un chemin par requête.

Exécutez bext bench compare <workload> --a <base> --b <head> localement pour reproduire la régression et itérer sur les correctifs avant de pousser à nouveau.

Conseil

La porte utilise une bande MAD statistique, et non un seuil fixe, de sorte qu'un bruit mineur ne déclenche pas de pannes. Un résultat doit dépasser 2 × le MAD des 10 dernières exécutions de référence — les valeurs aberrantes d’une seule exécution sont ignorées.

Remarque

Le tableau des fonctionnalités bext bench cost montre les frais généraux par fonctionnalité mesurés par bâtiment avec et sans chaque fonctionnalité. Si vous souhaitez comprendre pourquoi l'activation de v8 ajoute du RSS, ou si le WAF est le goulot d'étranglement, commencez par là avant de régler les budgets.

En rapport#

Surveillance — Métriques Prometheus pour la latence P50/P95/P99 en direct
Dépannage : problèmes élevés de processeur, de pipeline de transformation et de cache d'images
Architecture : pool de rendu V8 : restituer la topologie du pool de tâches qui gère la latence SSR
Guides : mise en cache — TTL et mécanismes de revalidation obsolètes qui affectent les taux de réussite du cache
Configuration : créer des indicateurs — indicateurs de fonctionnalités au moment de la compilation reflétés dans le tableau des coûts