Un test de charge qui se mesurait surtout lui-même
k6 setup() login requests landed in the same http_req_duration metric as the GETs under test, so bcrypt cost inflated p95 latency.
Le filet avait un trou
Le test, le journal d'audit, le scanner, la CI — couvrant moins que je ne le supposais.
En construisant l'installation k6, j'ai ajouté une phase setup() qui connectait 20 comptes et distribuait les jetons entre les VU. La première vraie campagne a semblé fausse immédiatement : p95 de 229 ms pour de simples GET sur une stack sans charge notable.
Ces POST de connexion font chacun un vrai bcrypt.compare — lent par conception, c'est le but — et ils atterrissaient dans la même métrique http_req_duration que les GET qui m'intéressaient vraiment. Avec peu de requêtes totales dans une campagne précoce, 20 connexions lentes tirent le centile agrégé bien au-dessus de la latence réelle de l'endpoint.
J'ai étiqueté séparément les connexions de setup et les requêtes de test et cadré les seuils sur l'étiquette de test. Tout script de charge avec une phase de setup non triviale a besoin de ses propres étiquettes, parce que la plupart des outils regroupent tout dans un seul histogramme par défaut, et un premier résultat étonnamment mauvais vaut la peine d'être vérifié pour ça avant de blâmer le système.