Discussion :

[saturn1]

Bonjour,
une question qui revient assez souvent sur internet:

Que choisir parmi select poll ou epoll pour faire un server qui doit supporter un nombre de connexion simultanee assez important.

J'ai vu qu'avec select la limite est environ de 1000 liee au fd_setsize.
Poll permet de pallier ce probleme mais est-ce performant par exemple si on passe 10 000 fds a poll peut-il tenir la charge?

Quel est la limite raisonnable de nombres de socket que peux gerer un server simultanement ? car la limite de fds ouverts est environ 200 000.

Merci

[Obsidian]

Bonjour,

À mon avis, à ce stade, ça dépend beaucoup du système que tu utilises.

[saturn1]

Du systeme ?
Tu entends par la, la puissance de la machine ?

Pour te repondre je ne sais pas encore exactement le prix que je vais mettre dans le server.

Mais sur un meilleur rapport qualite/prix, quel prix faudrait - il investir sur un server pour combien de client maxi ?

Merci

[Obsidian]

Je veux dire du système d'exploitation. Quand on a des programmes complètement uniformisés, portables, exploitant uniquement une A.P.I. normalisée (ex : POSIX), la différence sur les systèmes se fait sur ce genre de considération.

Je n'ai pas l'habitude des hautes montées en charge, donc je ne peux pas te répondre directement sans faire moi-même une étude préalable (d'autres, peut-être), mais à vue de nez, un bon *BSD avec beaucoup de mémoire (le plus important) et un processeur rapide parce qu'à 10000 connexions, il faut commencer à mouliner pour tenir la cadence et toutes les digérer, devrait faire l'affaire.

Ça dépend aussi de ce que tu comptes servir. Si ce sont de petites pages web facilement transmises, il y a des chances que tout tienne dans le cache et il n'y aura pas de souci. Si, en revanche, c'est un serveur d'applications et/ou de fichiers, avec autant de trafic montant que descendant, alors il faudra également se pencher sur la vitesse des bus, sur le type de disques que tu utilises et sur leur répartition.

[ram-0000]

1000 simultané, je partirais sur du spécifique OS.

Pour Windows avec IoCompletionPort c'est ce qui tiendra le mieux la route. C'est un peu délicat à programmer mais c'est avec cela, que tu auras le moins de problème de performances.

Pour Unix, je ne sais pas.

[spin0us]

Je suis en plein dans le même type de problématique que toi, à ceci prêt que j'ai déjà expérimenté les limitations du système.
Dans mon cas c'est donc un serveur multi-client qui doit encaisser plus de 2000 connexions simultanées avec pour chaque client un dialogue continue (donc bye bye le cache).

Première limitation : select (pas plus de 1024 en écoute)
Seconde limitation : les I/O (mon programme quand il dialogue avec ses clients stock certaine partie de discussion dans des fichiers. Ça implique donc énormément d'accès disque.)

La plateforme est un serveur mono proc (celeron 2.4Ghz) avec 2 Go de ram et 80Go de disque. Le CPU n'atteint pas ses limites. Le disque par contre ... ben il rame. Après plusieurs analyse de perfs pendant la charge, il apparaît que c'est en lecture qu'il à le plus de mal. Maintenant dans mon cas, j'ai aussi un base de données mysql fortement sollicitée, et pas mal de scripts qui tournent en parallèle de tout ça pour servir les informations utiles pour le dialogue avec les clients.

Pour le moment, niveau solution :
- epoll pour remplacer le select => limitation dépassée
- inotify pour éviter les accès disque non nécessaires

Je suis désormais confronter à une autre limitation : inotify et son max_user_instances.

J'ai fait pas mal de recherche sur le net concernant les serveurs multi-clients fortement chargés et malheureusement il n'y a pas tellement de matière sur ce sujet.