Les API de multiplexage des sockets utilisées par node.js (epoll(7) ou kqueue(2)) scalent le nombre de connexions en O(1), il est connu qu'on peux accepter un nombre quasiment infini de connexions dormantes. Aucun mérite :). Le chiffre peut impressionner parce qu'il ne correspond pas à ce qu'on compte habituellement : "100 000 connexions simultanées", ce n'est pas "100 000 connexions par seconde" et encore moins "100 000 requêtes GET par seconde".
Mais je parlais des firewalls à état traversés pour atteindre les node.js, pas des serveurs applicatifs node.js eux-même (pour autant que ces firewalls soient aussi utilisés pour autre chose que maintenir des connexions vides, ie. router du vrais traffic).
> 1 server (32GB of RAM, quad core), mais seulement 1 à 2 Go de RAM
> serait utilisé avec node.js (Netty uses 10-20GB depending on the traffic
> level. node.js uses around 10x less than that).
En même temps, le bougre ne supporte pas les architectures 64 bits, si j'en crois la doc. Il aurait donc bien du mal à utiliser plus - même lorsqu'il serait pertinent de cacher des choses en ram...
[^] # Re: Les adminsys en redemandent
Posté par herodiade . En réponse à la dépêche Les technos web cools du moment. Évalué à 3.
Mais je parlais des firewalls à état traversés pour atteindre les node.js, pas des serveurs applicatifs node.js eux-même (pour autant que ces firewalls soient aussi utilisés pour autre chose que maintenir des connexions vides, ie. router du vrais traffic).
> 1 server (32GB of RAM, quad core), mais seulement 1 à 2 Go de RAM
> serait utilisé avec node.js (Netty uses 10-20GB depending on the traffic
> level. node.js uses around 10x less than that).
En même temps, le bougre ne supporte pas les architectures 64 bits, si j'en crois la doc. Il aurait donc bien du mal à utiliser plus - même lorsqu'il serait pertinent de cacher des choses en ram...