Nodefony peut-il partir en production ?
Trois mesures — débit à travail égal, tenue dans la durée, dimensionnement d'un pod — et ce qu'elles ne prouvent pas.
Le verdict
La performance n'est pas le point faible de Nodefony. À travail égal — c'est-à-dire
face à un Express muni des mêmes middlewares (scope ALS, CORS, en-têtes de sécurité, contrôle CSRF,
corrélation traceparent, zones de pare-feu) — le framework rend
112,7 % du débit pour −0,20 ms
de p99, et 93,6 % de celui d'un NestJS qui fait le
même travail : la même zone, pour une résolution de banc de 3 %. L'écart avec un serveur nu ne mesure pas une lenteur : il mesure le travail que le serveur nu
ne fait pas.
Sur 88 minutes de charge continue, le tas ne monte pas et le débit ne s'érode pas. Le risque résiduel d'un passage en production n'est donc pas la performance — il est nommé plus bas.
Le dossier, en 5 pages
Ce que ces chiffres ne disent PAS
Un rapport qui ne montre que ses bons résultats rassure au lieu d'aider à décider. Les limites de cette campagne, nommées :
- 88 minutes ne sont pas trois jours. Ce soak élimine les fuites grossières. Une fuite lente — quelques mégaoctets par heure — resterait invisible ici et tuerait un pod au bout d'une semaine.
- Aucune valeur ABSOLUE n'est transposable. Poste de développement, macOS, 12 cœurs logiques, base SQLite dans le processus. Les comparaisons à l'intérieur de cette page sont valides (même décor des deux côtés) ; les chiffres bruts, non.
- Le multi-pod sous trafic réel n'est pas couvert ici — fan-out entre pods, backplane Redis, cohérence des sessions. D'autres bancs le font, pas celui-ci.
- Le démarrage à froid coûte. Un pipeline riche présente plus de fonctions distinctes à optimiser au JIT : les premiers milliers de requêtes d'un pod neuf sont plus lentes. À couvrir par une sonde de disponibilité qui attend, ou un préchauffage.
- Aucune mesure ne remplace des heures de vol. C'est le déficit réel, et il ne se comble pas en codant : il se comble en étant déployé.