Version imprimable
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 :)
select() ou poll() + pthreads, c'est impec.Citation:
Envoyé par |PaRa-BoL
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).
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
Oui c'est plus un probléme de ressource si je comprends bien.
Voilà exactement.Citation:
Envoyé par hegros
Tu demandais siDans 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 :)Citation:
Envoyé par
|PaRa-BoL
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).
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.
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.
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 ?Citation:
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 !
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.
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')
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.Citation:
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 ?
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.
Ah c'est intéressant. Je vais me documenter la dessus !Citation:
lighttpd prétend par exemple être 3 fois plus rapide qu'apache grâce à cette approche.
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 :)