Discussion :

[|PaRa-BoL]

Bonjour,

Je voudrai savoir qu'elle est la meilleur solution pour programmer un serveur qui accueil plusieur clients.

Gérer les files descriptor avec select() ou poll() ?

J'ai pensé sinon à créer un thread par client connecté mais n'est-ce pas trop lourd ?

Si mon serveur accueil 2000 connectés, qu'elle est la meilleur solution ?
(Sachant qu'il n'y aura que de l'échange de texte)

Merci

[Emmanuel Delahaye]

Si mon serveur accueil 2000 connectés, qu'elle est la meilleur solution ?
(Sachant qu'il n'y aura que de l'échange de texte)

select() ou poll() + pthreads, c'est impec.

[bigquick]

Un bon système pour éviter d'allouer 2000 threads dès le départ, ou d'en réallouer en permanence, est le modèle répartiteur / ouvriers (Thread pool).

Tu peux créer un pool de X threads (mettons 100). A chaque connexion, tu vas associer le client à un thread libre (qui devient alors occupé). Lorsque tous les threads sont occupés, le nouveau client doit patienter. Lorsqu'un client se déconnecte, "son" thread redevient libre, et peut s'occuper des clients en attente (ou attendre en se tournant les pouces si la salle d'attente est vide)

Ca permet entres autres de ne pas surcharger le serveur en cas de connexions trop nombreuses, et de gérer facilement le nombre de connexions simultanées supportées.

note: Lorsque tous les threads sont trop souvent occupés, tu peux aussi décider d'en allouer un nouveau paquet: embauche de Y nouveaux ouvriers (pour une durée déterminée ou non).

[|PaRa-BoL]

Merci de vos réponses,

Donc si je comprend bien l'avantage de la solution du "Thread Pool" est que cela évite les charges de création et destruction des threads ?

Merci

[hegros]

Oui c'est plus un probléme de ressource si je comprends bien.

[bigquick]

Oui c'est plus un probléme de ressource si je comprends bien.

Voilà exactement.

Tu demandais si

créer un thread par client connecté [...] n'est pas trop lourd ?

Dans l'absolu, non, mais si 300 clients se connectent d'un coup, tu vas devoir créer 300 threads "en même temps" ce qui n'est pas idéal. Et aussi détuire ceux-ci à la fin des transactions, alors que si ca se trouve 300 autres clients vont se connecter dans les 5 secondes qui suivent

De plus, même si tu dois pouvoir gérer 2000 clients, as-tu vraiment besoin de les gérer simultanément ? Par exemple, si chaque transaction dure 2 secondes, c'est peut-être (ça dépend du contexte) raisonnable de gérer 400 clients à la fois, et de faire attendre les autres quelques secondes que la place se libère. Ou encore, que doit-t-il se passer si plus de 2000 clients se connectent à ton serveur ?

C'est des questions qui doivent t'amener à reflechir au meilleur design possible (celui du pool de thread n'est pas idéal pour tous les cas, mais c'est généralement un bon compromis).

[loufoque]

Tu n'as pas besoin de threads, tu peux tout gérer en asynchrone avec select() ou /dev/poll ou epoll() ou kqueue, ce qui d'ailleurs sera plus performant au final.

[bigquick]

Euh je vais peut-être dire une bétise .... mais comment faire pour traiter les clients de manière asynchrone sans threads ? Select (par exemple) va faire une attente passive, et se reveiller lors de l'activation d'un descripteur.

La primitive select (4.3 BSD) surveille un ensemble de descripteurs, si aucun n'est actif le processus est endormi et ne consomme aucune ressource cpu. Dès que l'un des descripteurs devient actif (il peut y en avoir plusieurs à la fois) le noyau réveille le processus et l'appel de select rend la main à la procédure appelante avec suffisemment d'information pour que celle-ci puisse identifier quel(s) descripteur(s) justifie(nt) son réveil !

Il faut ensuite traiter cette activation, et si ce c'est pas à l'aide de threads (ou de fork, mais bon ... ), ce traitement va se faire de manière synchrone. Le prochain appel a select ne se fera qu'une fois le traitement terminé, non ?

[gene69]

Ou est ce que je peut trouver plus de détail sur les poll (du genre un exemple) (je vais demander à google)

Pour les 200 thread, ça m'étonne que se soit possible, j'ai jamais réussi à creer plus de 380 thread sous debian.

[granquet]

le meilleur "tutorial" sur ce sujet que j'ai pu trouvé sur le net: http://beej.us/guide/bgnet/

tu peux gerer avec select dans une appli 'mono-thread', un bon paquet de clients(apres ca depend de tes imperatifs 'temporels')

[loufoque]

Il faut ensuite traiter cette activation, et si ce c'est pas à l'aide de threads (ou de fork, mais bon ...), ce traitement va se faire de manière synchrone. Le prochain appel a select ne se fera qu'une fois le traitement terminé, non ?

Oui, mais tu ne fais que traiter le bout de données reçu, et généralement tu n'as pas besoin d'opération bloquante pour cela.
En fait on utilise un système évenementiel pour savoir quand est-ce qu'il y a des données à lire.

lighttpd prétend par exemple être 3 fois plus rapide qu'apache grâce à cette approche.

[bigquick]

lighttpd prétend par exemple être 3 fois plus rapide qu'apache grâce à cette approche.

Ah c'est intéressant. Je vais me documenter la dessus !

Pour l'instant je ne vois pas trop comment ça peut se passer pour les gros traitements (envoi de fichier par exemple), mais je vais voir tout ça sur la page de lighttpd