> Oui, mais "100 000 connexions simultanées" nécessite de conserver un contexte en mémoire,
Le coût système (non applicatif) mémoire de la conservation de sockets TCP established est évaluable. Je ne connais pas la surcharge spécifique de libev (utilisée par node.js), mais c'est vraisemblablement du même ordre que pour la libevent, pour laquelle les valeurs sont connues :
Voir la seconde partie de ce test (l'implem en C avec libevent) de Richard Jones (de Last.fm, qui semble largement plus sérieux que le gars de Plurk btw) :
1 *million* de connexions consomme moins de 2 GB (userland, RSS) + kernel, avec libevent.
"I connected 1M clients to the httpdcnode server using the same client as above, the machine showed a total of just under 10GB or memory used. The resident memory of the server process was stable at under 2GB". "the resident memory per connection for the server process with libevent is just under 2KB. [...] the kernel/tcp stack is consuming an additional 8KB per connection". http://www.metabrew.com/article/a-million-user-comet-applica(...)
Un autre test du même genre (mesure du cout de connexions http persistentes et dormantes en utilisant libevent) : "Resources now jumped to a maximum of 21MB resident (25MB virtual) for 200,000 working connections, but once again the OS was showing ~450MB extra memory used" http://aleccolocco.blogspot.com/2008/10/gazillion-user-comet(...)
Un autre exemple spécialement pour toi ;) : la doc de djabberd (en Perl, utilisant epoll) affirme, dans le même ordre (ie. sans détails) que "A recent test had 300k connections in 1GB of RAM". cf. http://www.danga.com/djabberd/#perf
Ça donne une idée du coût système des connexions.
Reste à savoir le cout des états applicatifs node.js associés, qui dépendent évidement de ce qu'on fait (en terme "métier"/application) avec toutes ces connexions, et c'est ce qui n'est pas indiqué dans le "wow mon node.js tient 100 000 connexions simultanées"... 1KB (largement de quoi stocker un cookie et une position dans une machine à état simple) par connexion coûte dans ces conditions 100 MB au total.
> et peut-être du keepalive.
Du keepalive HTTP il y en a forcément ; c'est la fonctionnalité HTTP fondamentale sur laquelle repose Comet, et c'est bien pour ça que le "100 000" n'a pas trop de sens, car on ne parle pas de 100k nouvelles connexions + req GET par seconde, il s'agit de 100k connexions établies progressivement sur un laps de temps indéterminé, dormantes, et maintenues au cas où le serveur aurait quelque chose à signaler au client. Cela dit ça doit être cocasse lorsqu'ils mettent à jour l'appli ou redémarrent le serveur, et se reprennent les 100k connexions simultanément d'un seul coup dans la face.
Si tu parle du keepalive TCP (SO_KEEPALIVE), ça ne coûte (par défaut sous Linux) rien pendant les 2 premières heures, et ensuite une paire de paquets toutes les 75s (net.ipv4.tcp_keepalive_intvl et net.ipv4.tcp_keepalive_time). Pas trop violent ;)
[^] # Re: Les adminsys en redemandent
Posté par herodiade . En réponse à la dépêche Les technos web cools du moment. Évalué à 3.
Le coût système (non applicatif) mémoire de la conservation de sockets TCP established est évaluable. Je ne connais pas la surcharge spécifique de libev (utilisée par node.js), mais c'est vraisemblablement du même ordre que pour la libevent, pour laquelle les valeurs sont connues :
Voir la seconde partie de ce test (l'implem en C avec libevent) de Richard Jones (de Last.fm, qui semble largement plus sérieux que le gars de Plurk btw) :
1 *million* de connexions consomme moins de 2 GB (userland, RSS) + kernel, avec libevent.
"I connected 1M clients to the httpdcnode server using the same client as above, the machine showed a total of just under 10GB or memory used. The resident memory of the server process was stable at under 2GB". "the resident memory per connection for the server process with libevent is just under 2KB. [...] the kernel/tcp stack is consuming an additional 8KB per connection".
http://www.metabrew.com/article/a-million-user-comet-applica(...)
Un autre test du même genre (mesure du cout de connexions http persistentes et dormantes en utilisant libevent) : "Resources now jumped to a maximum of 21MB resident (25MB virtual) for 200,000 working connections, but once again the OS was showing ~450MB extra memory used"
http://aleccolocco.blogspot.com/2008/10/gazillion-user-comet(...)
Un autre exemple spécialement pour toi ;) : la doc de djabberd (en Perl, utilisant epoll) affirme, dans le même ordre (ie. sans détails) que "A recent test had 300k connections in 1GB of RAM". cf. http://www.danga.com/djabberd/#perf
Ça donne une idée du coût système des connexions.
Reste à savoir le cout des états applicatifs node.js associés, qui dépendent évidement de ce qu'on fait (en terme "métier"/application) avec toutes ces connexions, et c'est ce qui n'est pas indiqué dans le "wow mon node.js tient 100 000 connexions simultanées"... 1KB (largement de quoi stocker un cookie et une position dans une machine à état simple) par connexion coûte dans ces conditions 100 MB au total.
> et peut-être du keepalive.
Du keepalive HTTP il y en a forcément ; c'est la fonctionnalité HTTP fondamentale sur laquelle repose Comet, et c'est bien pour ça que le "100 000" n'a pas trop de sens, car on ne parle pas de 100k nouvelles connexions + req GET par seconde, il s'agit de 100k connexions établies progressivement sur un laps de temps indéterminé, dormantes, et maintenues au cas où le serveur aurait quelque chose à signaler au client. Cela dit ça doit être cocasse lorsqu'ils mettent à jour l'appli ou redémarrent le serveur, et se reprennent les 100k connexions simultanément d'un seul coup dans la face.
Si tu parle du keepalive TCP (SO_KEEPALIVE), ça ne coûte (par défaut sous Linux) rien pendant les 2 premières heures, et ensuite une paire de paquets toutes les 75s (net.ipv4.tcp_keepalive_intvl et net.ipv4.tcp_keepalive_time). Pas trop violent ;)