Dimensionner un pod

Des constantes mesurées, un calculateur, et ce que le modèle suppose.

Les constantes d'un pod

Mesurées par capacity.mjs en production, Node v26.10.0, commit 7e994abd, le 2026-10-02 : 3 runs de 8 s par constante, messages WebSocket de 1 024 octets, serveur saturé (ELU relevé pendant la charge). Une constante dont les runs divergent de plus de ±5 %, ou dont l'ELU n'a pas été relevé, n'est pas affichée. Le CPU du fil principal vient de la campagne de comparaison, pas de ce banc ; le débit HTTP d'un pod aussi — ce banc charge le serveur depuis un client Node, plus lent que wrk, et son débit HTTP n'est pas publié.

L'écho WebSocket en clair sort plus lent qu'en TLS sur ce banc (35 367 contre 45 947 msg/s). Ce n'est pas un gain du TLS : c'est la façon dont Node lit un trafic en rafale (ici 16 messages en vol par socket), reproduite sur un serveur ws nu, sans Nodefony. Le déchiffrement remet au serveur des blocs qui portent plusieurs messages ; en clair, chaque segment le réveille presque seul — un appel système, un rappel, une analyse de trame. Mesuré sur le serveur nu, en messages par lecture : 6,8 contre 2,4 à 5 octets, 5,4 contre 2,2 à 1 Ko. Le coût fixe d'une lecture domine tant que les messages sont petits ; à 4 Ko le clair repasse devant (~45 000 contre ~40 000 msg/s, séries séparées). Preuve rejouable : ws-tls-batching.mjs.

RAM par socket WebSocket

10,2 Ko

tas retenu, TLS terminé en amont · TLS terminé par Node : non publiable (runs de 11,9 à 14,1 Ko)

Latence à vide (HTTPS)

0,13 / 0,24 / 0,34 ms

p50 / p95 / p99, une requête à la fois

CPU du fil principal

45,7 µs/req

face à 42,9 µs/req chez NestJS équipé

Écho WebSocket

45 947 msg/s

en TLS · 35 367 msg/s en clair · diffusion 1→100 : 196 719 livraisons/s

Trafic visé (requêtes/s)

Charge max par pod (%)

RAM allouée par pod (MB)

Sockets WebSocket simultanées

La mémoire par socket retenue est celle du TLS terminé en amont : la mesure avec TLS terminé par Node n'est pas publiable pour cette version. Le débit par pod (21 686 req/s) vient du comparatif ci-dessus, mesuré sur une route sans base de données. Une route qui lit et écrit une base — le banc applicatif, vingt lectures puis une écriture SQLite — descend à ~1 117 req/s sur ce même poste : c'est la base qui borne. Pour dimensionner un déploiement réel, refaire la mesure sur la cible, avec sa base.