Campagne de test — Nodefony 10.0.0
Aucune régression du produit. Tous les rouges sont instruits et imputés au décor ou à l'instrument.
Le verdict
Cas passés
11 701
passage le plus large (étage A)
Régressions du produit
0
aucune
Rouges de décor ou d'instrument
16
n'appartiennent pas au code
Cas non exécutés
249
sur ce même passage
Les étages se recouvrent — C1 rejoue le socle avec des interrupteurs ouverts. Ces chiffres sont donc ceux du passage le plus large, jamais une somme : additionner compterait trois fois la même suite. Et un total ne dit rien seul — 249 cas n'ont pas tourné sur ce seul passage, un cas sauté comptant comme vert. Ce que la campagne n'a pas éprouvé est en bas de page, au même rang que le reste.
Ce qui a été joué, étage par étage
A — Non-régression + dialectesnpm run test:all -- --dialects | L unique rouge est un flake de saturation : 15/15 en 2,4 s isolé. | 11 701 | 1 | 249 | 9,8 min | ● vert |
B — Charge + mémoirenpm run test:all -- --load | Gate mémoire 9/9, marges ×10 à ∞. | 10 147 | — | 177 | 3,4 min | ● vert |
C1 — Interrupteurs perf / boots CLI / clusterNF_RUN_PERF=1 NF_RUN_CLI_BOOT=1 NF_RUN_CLUSTER_E2E=1 npm run test:all | 114 tests de plus exercés. Les 9 rouges sont tous du décor, verts en isolé. | 10 217 | 9 | 61 | 13,8 min | ● instruit |
C2 — Sondes de rupture WebSocketrun.sh load --rupture | Plafond 8 000 sockets ; 100 000 frames sans perte. | 7 | — | 22 | 2,1 min | ● vert |
C3 — Coupures RÉELLES de baseNF_RUN_DB_OUTAGE=1 + conteneurs nommés | PostgreSQL, MariaDB, MongoDB arrêtés et relancés ; bascule de primaire comprise. | 15 | — | — | 1,8 min | ● vert |
D — Bancs e2e et de mesurepar lots (catalogue nodefony-load-test) | 20 bancs e2e + 13 bancs de mesure, après correction de 4 décors mal classés. | 33 | — | — | ~25 min | ● vert |
E — Ce que le scaffold produitverify-generated.mjs --keep puis verify-runtime.mjs | Vérité et conformité (3 étages) vertes. Le contrôle de FORMAT est cassé et orphelin → #215. | 2 | 1 | — | ~12 min | ● instruit |
F — Multi-podssetup.sh puis run.sh + matrice d attaque | Attaque du bus 5/5 et 4 mesures vertes. Les 3 bancs de pod face à leur base exigent une base adoptée → #216. | 9 | 3 | — | ~15 min | ● instruit |
G — Chaîne de publicationnpm run release:pack puis release:smoke | 15 tarballs ; 3 scénarios (base, front, studio) prouvés depuis une image vierge. | 3 | — | — | ~8 min | ● vert |
Les rouges, triés par cause instruite
Sur une campagne complète, le produit est le dernier suspect. Chaque rouge est instruit avant d'être imputé : le même cas passe-t-il isolé (saturation) ? le décor est-il celui que le banc suppose ? un état partagé s'est-il accumulé ? l'instrument dit-il vrai ?
| ● saturation | 7 | @nodefony/realtime — clusterIpc.e2e ×5, redisCluster.e2e ×2 | worker fork: ready timeout (5 s / 6 s) | 5/5 puis 2/2 verts en isolé ; fan-out Redis mesuré p50 53 ms / p99 60 ms. |
| ● saturation | 1 | @nodefony/drizzle — migrate-adopt | timeout 20 s puis ENOTEMPTY au retry | vert isolé en 1 054 ms. |
| ● état partagé | 1 | @nodefony/http — session-revocation | garde-fou de pagination : expected 60 to be below 60 | 5 816 sessions résiduelles dans Redis ; après purge, 7/7 en 571 ms contre 48 539 ms. |
| ● instrument | 1 | racine — format:scaffold | npm error 404 sur @nodefony/devkit | génère sans installer depuis les tarballs ; branché dans aucun workflow. → #215 |
| ● décor | 3 | multi-pods — db-outage / db-readiness / db-persistance | NF_MIGRATE_BASELINE_REQUIRED | exigent une base adoptée, que rien ne documente. → #216 |
| ● instrument | 3 | bancs de charge — scaffold-ws-probe, app-download-probe, poc-hmr-perf | method not found: scaffold:run ; ws error | deux bancs périmés, un défaut d URL en clair face à un Vite en TLS. → #217 |
Seuils mémoire
| 1 000 GET séquentiels | -0,44 | 35 | ∞ |
| 100 crashs synchrones | 0,09 | 10 | ×111,1 |
| 100 crashs asynchrones | 0,07 | 10 | ×142,9 |
| 100 TypeError natifs | 0,10 | 15 | ×150,0 |
| 500 requêtes mixtes | 1,88 | 20 | ×10,6 |
| 200 envois multipart | 0,92 | 30 | ×32,6 |
| 100 connexions WS | 0,00 | 30 | ∞ |
| 50 allers-retours WS | 0,02 | 25 | ×1 250,0 |
Capacité d'un pod
| http/1.1 (clair) | 2 409 | ±19 % | 0,62 | 99 % |
| https/1.1 (TLS) | 2 911 | ±3 % | 2,46 | 93 % |
| h2 (multiplexé) | 3 229 | ±3 % | 0,75 | 90 % |
Plafond WebSocket
8 000 sockets
13.33 KB par connexion
Écho WebSocket
10 303 msg/s
1 pour 1
Diffusion
381 578 liv./s
1 vers 100 sockets
Latence cross-pod
3 ms (p50)
50 000 livraisons, 0 % de perte
Décor : Hyperviseur actif pendant la campagne (Docker Desktop, 8 vCPU réservés sur 12) — les ABSOLUS ne sont pas transposables, les comparaisons intra-fenêtre le sont. Ces chiffres situent un ordre de grandeur ; ils ne se transposent pas à une autre machine.
Tenue dans la durée — la pente que le nombre cache
Trois runs, trois décors. Le tas V8 reste plat et les handles ne bougent pas : ce n'est pas une fuite d'objets. Le RSS monte, mais ce compteur est trompeur sous macOS — il inclut les pages que l'allocateur a déjà rendues au noyau. Mesurée à part, l'empreinte système reste plate (164 → 164 MB sur 29 fenêtres), et
leaks ne trouve que 3 Ko sur 20,7 millions de requêtes.| Run | Durée retenue | Décor | Tas | Handles | Verdict du banc |
|---|---|---|---|---|---|
| run1 | 13 min retenues | machine chargée | plat (+0,4 MB) | stables | INDÉTERMINÉ (< 10 min) — et empreinte système non mesurée |
| run2 | 84 min retenues | décor NON tenu (charge montée à 10,89) | plat (+0,5 MB) | stables | hausse du `rss` seul — NON CONCLUSIF : l'empreinte système n'a pas été relevée |
| run3 | ~68 min utiles | machine libre | plat (44,2 MB constant) | stables | `rss` 255 → 371 MB ; serveur arrêté à la fenêtre 35 (échéance de dérogation) — NON CONCLUSIF, et le « plateau » annoncé est un artefact |
Deux réserves, et la seconde annule la conclusion que ces courbes semblaient porter. (1) La chute finale du troisième run n'est PAS une mesure : le serveur s'est arrêté à l'échéance de sa dérogation aux modules de développement, et le banc a moyenné cette mort dans sa régression — d'où un « plateau » qui n'existe pas. (2) Ces trois runs n'ont relevé que
rss. Sous macOS, ce compteur inclut les pages que l'allocateur a déjà rendues au noyau ; mesuré depuis sur le même décor, il s'agit de 93 % de la hausse. L'empreinte réelle du processus, elle, ne bouge pas. Ces courbes montrent donc un compteur qui monte, pas une mémoire qui se consomme.Ce que cette campagne n'a PAS éprouvé
Un banc sauté compte comme vert. Cette liste est la moitié du verdict.
- Le front d une application générée (le banc de vérité ne monte pas Vite).
- Les dialectes PostgreSQL et MySQL du code généré (seul sqlite a été joué).
- Le comparatif de frameworks et l A/B de production mono — écartés pour ne pas fausser les mesures en cours.
- La tenue au-delà de 90 minutes : aucun run ne prouve trois jours.
- Les bancs de découvrabilité et de schéma du devkit (agents réels, coût dédié).