Passage d'un server multiprocess à un serveur multi-threadé.

Bonjour !

J'ai une petite question déstiné aux experts en serveur.
Actuellement, j'ai un serveur de répartition de taches qui tourne en multi-process (je fais un fork() pour chaque client qui se connecte)... mon code fait à peu pres 80Ko.
Le nombre de requetes n'est pour l'instant pas tres grand, de l'ordre de, disons, 1 requete par seconde, en moyenne.

Mais l'utilisation de mon serveur par un autre serveur, risque de faire monter le nombre de requete à 10 par seconde, voir 100.

Donc j'aimerai savoir si ca vaut le coup que je change la structure de mon serveur pour le rendre multi-threadé... Le jeu en vaut-il la chandelle, ou alors le gain ne sera pas enorme ?

Merci de vos conseils.

Beh le truc c que je sais que le nombre de processus par machine est limité mais paramétrable donc au bout d'un certain nombre de process tu ne pourras plus en creer a moins que tu les tues au fur et a mesure

Que dire de plus ? :)

Par contre je sais pas si on est limité a un nombre de thread par processus

Oui, en fait ce je le sais deja ;) Mais merci quand meme ;)

En fait je cherche l'avis de quelqun qui a deja ete expose à cette situation, et qui a vu une difference notoire entre un serveur multi-process et un serveur multi-threadé...

Voila...

En fait une difference entre un server multiproc et un multithread et le fait que ton server ne possedera plus le CPU pour lui tout seul mais devra le partager avec tous les fils qu'il a creer d'autre part je ne crois pas qu'il existe une limite vraiment handicapante concernant le nombre de thread.
Enfin ca je suppose que tu le savais deja...(c'est pour ca que j'enclenche pas sur les mutex et co)

Tout ce que je sais c'est que la plupart des gros server d'echange de fichiers et autre son concus en multithread pour justement eviter la contrainte du nombre de process.

De plus de nos jours les lib de thread sont tres performantes donc pas de probleme.

Voila....

Et j'ajouterai que lancer une thread est moins couteuse en CPU que lancer un fork(), donc si tu dois gerer un nombre de connections important, je te conseille doublement les threads.
Sinon, pour ameliorer les performances, tu peux faire un systeme de "pre-fork" ou tu lances a l'ouverture de ton serveur un nombre defini de thread ou de processus qui prendront en charge les connections entrantes.
Tu ne creera ainsi que si tes requetes depassent le nombre de thread/processus lancer au demarrage. et donc, tu economisera le temps de lancement pour les premieres connections. (pour info, c'est ce que fait apache).

Salut

Merci de vos réponses, meme si mon post date deja un peu ;)

Pour ce qui est de la légereté des thread, c'est clair, ca je ne le nie pas... non, en fait le vrai problème c'est que je dois faire un code portable (Unix/Linux) sur des systemes qui n'ont pas forcément toutes les libs voulues (je pense notemment aux fonctions réentrantes nécéssaires pour travailler avec des threads, mais qui ne sont pas dispo sur certains systemes... hcreat() par exemple). Donc je suis contraint, si je veux utiliser les threads, de réécrire mes propres fonctions reentrantes, chose assez fastidieuse.

Par contre, darkalia, tu me parles de creer des process à l'avance... C'est un concept que je connais, mais je ne sais pas comment tu fais pour leur "passer" la connection acceptée par le serveur principal... Tu peux m'eclairer STP ?

Autre petit PS : si les thread sont si performants, pourquoi Apache, par exemple, n'est pas concu avec des threads (je le suppose, d'apres darkalia)?

D'abord je vais repondre a la 2e question.
Apache marche avec les deux:
process et threads. Il a d'ailleurs nettement ete optimiser grace a ca, car avant, ses performances sous windows etait desastreuse, car il marchait essentiellement avec les process.
Apache, si mes souvenirs sont bons, lance un processus principal dans lequel va tourner le serveur. Il lance ensuite quelque process, qui vont chacun se mettre a creer des threads, pour une thread par connection.
Des que le quota de thread est depasser, apache relance un nouveau process et ainsi de suite.

Ensuite, pour "passer" la connection, il suffit de faire un select dans ton serveur principal, puis au moment ou tu accepte une connection, creer un thread/process et lui passer la socket recuperee. Et c'est dans la routine de la thread ou le code du process que tu feras tes traitements de socket.

edit : pour le code portable, ou tu fais des #ifdef dans des fonctions, en essayant de rendre ton code modulaire, sinon, tu peux utiliser la lib pthread il me semble qui existe aussi bien sous win32 que unix.

Salut,

Citation:

---

Il lance ensuite quelque process, qui vont chacun se mettre a creer des threads, pour une thread par connection.

---

Oui, cette technique je la connais bien, sinon je ne saurais pas faire de serveur ;) Mais je me demandais comment faire pour passer une connexion à un process déjà existant (les process lancés à l'avance par le maitre).

Sinon, tu parles de quota... c'est à dire qu'un process ne peut lancer qu'un certain nombre de threads, c'est ca ? Cette limite est à combien généralement ?

Pour le code portable, je sais qu'il faut faire des #ifdef, mais ce n'est pas ca qui va me fournir des fonctions réentrantes en C ANSI.
Mais bon, peut-etre ne devrais-je pas coder seulement en C ANSI ?[/quote]

Personnelement, je l'ai fait avec les threads en creant mes thread en mode "suspend" et en les resumant lors du passage de la connection, pour le process, un flag en attente devrait faire l'affaire.
J'insiste sur la presence du select, je pensais que ce la repondait a ta question.
Si tu veux du code portable, tu seras obliger de passer par les #ifdef, sauf si tu veux utiliser des lib exterieur.
Je ne retrouve plus l'url, mais une librairie appelle netboost pourrait bien repondre a tes besoins.
Sinon pour les limites, je t'avouerai que je n'en sais rien, pour la simple raison que je n'ai pas tester. Mais il me semble que l'OS a une limite de fd par process.
Ceci dit, si tu veux faire du code portable windows je te conseil de faire uniquement des threads, car l'instruction fork() n'existe pas, et la creation de nouveau process est lourde.
Et je te conseillerai egalement plutot le C++.

Pour passer les connections aux process, tu les fais juste ecouter la socket, ils vont se repartir les connections (pas forcement equitablement) automatiquement (avec listen).
La limite de threads depend des archis, je crois que sous FreeBSD ca devait etre autour de 65000... A verifier

Citation:

---

Personnelement, je l'ai fait avec les threads en creant mes thread en mode "suspend" et en les resumant lors du passage de la connection, pour le process, un flag en attente devrait faire l'affaire.

---

Pour les process, tu dis qu'un flag d'attente devrait faire l'affaire... mais je ne vois pas comme tu fais passer une connexion du process père (le serveur, qui ecoute sur un select) à l'un de ses fils déjà crée.

Pour les #ifdef, je suis d'accord, je n'ai pas le choix. Mais pour pour le moment, je ne me pose pas vraiment la question pour une portabilité Windows. Au fait, est-ce qu'il y a beaucoup de différence au niveau des fonctions réseau en C, entre Linux et Windows ?

Citation:

---

Pour passer les connections aux process, tu les fais juste ecouter la socket, ils vont se repartir les connections (pas forcement equitablement) automatiquement (avec listen).

---

Cela répond à ma question posée plus haut... je n'ai jamais essayé, alors je vais voir dès que j'en aurai l'occasion. Lorsque tu dis "pas forcément équitablement", c'est à dire ? De toute facon, si le process est occupé à faire qqch (apres un accept), c'est un autre en mode LISTEN qui devrait récupérer la connexion, non ?

Merci de vos réponses !

Citation:

---

Envoyé par Gogoye

Au fait, est-ce qu'il y a beaucoup de différence au niveau des fonctions réseau en C, entre Linux et Windows ?

---

La librairie Winsock est basée sur les sockets BSD. Elle a quelques spécificités (nécessité d'initialiser la librairie, fonction read/write indisponibles), mais un programme réseau Unix peut se porter assez facilement sous Windows. En revanche, Winsock apporte la notion de sockets asynchrones, pour notifier l'arrivée de données par messages plutôt que par blocage du processus comme les sockets bloquantes standard de BSD.

Les sockets asynchrones sont spécifiques à Windows, mais elles représentent aussi la manière la plus naturelle sous cet environnement d'utiliser les sockets.

Mais on peut aussi utiliser les fonction send() et recv() comme sous Unix, en mode bloquant ? Histoire de ne pas avoir à changer toute la structure du soft.

Citation:

---

Envoyé par Gogoye

Mais on peut aussi utiliser les fonction send() et recv() comme sous Unix, en mode bloquant ? Histoire de ne pas avoir à changer toute la structure du soft.

---

Oui, et encore heureux.
Les seules vraies incompatibilités dans le sens Unix :arrow: Windows, c'est l'utilisation de read et de write pour écrire sur les sockets. Il faut donc les remplacer par send() et recv().

Oki, bein c'est cool car en gros je ne devrait pas avoir trop de pb pour porter mon appli (mis à part les process) !

Les fonctions du genre vfprintf(), ou bien hsearch() sont aussi dispo sous Win ?

Edit : Et pour read() et write(), elles sont pas dispo que pour le réseau, ou alors aussi pour tous les descripteurs ? Si oui, comment on fait pour ecrire dans un fichier ? fread() / fwrite() ?

Sur www.msdn.com, tu trouveras toutes les infos necessaires pour les winsocks.
C'est un peu la page des man sous windows.
Sinon, je vois pas ton probleme avec le fait de passer une connection a un processus fils. Tu fait un listen dans le processus et cela devrait etre bon.
Par contre si tu veux recuperer dans le processus principal, il va falloir jouer avec les shm (shared memory) et les dup2. Et ca, ce n'est pas tres portable (enfin je trouve).
Je te conseille vraiment les thread pour la portabilite.

Ok, je penserai à réaliser mes prochains serveurs avec une structure threadée.

Merci pour les informations !