[quote name=‹ BokLM › date=’ 30 Mar 2005, 20:04’]Sous Linux grace entre autres au copy-on-write des pages memoires (toutes les pages memoire sont partagee entre les 2 process, jusqu’a ce qu’un des 2 process tente d’ecrire), un fork est super rapide et c’est pas une operation tres tres couteuse en memoire ou cpu. Pour un serveur web comme apache, c’est un peu mieux en pre-forkant, mais a mon avis ca pourrait quand meme fonctionner a une vitesse correcte en forkant a chaque fois (mais c’est loin d’etre le cas sous Solaris).
Sinon, ouais, comme l’a dit Unreal, un proces sert un nombre limite de requetes avant de mourrir, donc nouveaux process assez regulierement …
[right][post=« 345707 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Parceque c’est clair qu’un process comme Apache ecrit jamais en memoire
Minimiser le cout initial et le decaler a plus tard ne change rien. Le cout des context switch est toujours enorme, le cout des fautes de pages dans le(s) cache(s) du CPU aussi. Y a des fois faut juste arreter de vouloir justifier n’importe quoi, alors qu’il y a meme pas besoin de justifier quoi que ce soit. « ca pourait fonctionner a vitesse corecte en forkant a chaque fois » mais bien sur, et puis des I/O synchrones de partout aussi tient tant qu’on y est. Apres tout le server web que tout etudiant fait en Java ou en C dans ses etudes en projet marchait tres bien…
Heureusement que certains s’en contentent pas. Et dans le meme genre « les memory leaks meme pas mal sous apache » faut arreter deux secondes de raconter n’importe quoi d’aussi irrealiste. Oui les process sont recycles apres un certain nombre de requetes, genial, evidemment, tu fais pas du trois 9 sans des mesures de ce genre. Mais la limite est d’ailleurs par defaut haute (10 000 sans compter les keep-alive), autant dire que avec presque une dizaine de process lance, tu peux tourner longtemps sans recycler un seul process. « Assez regulierement » est tres relatif, on parle d’a peine une fois par jour pour beaucoup de sites. Leak 1Ko a chaque requete (pas enorme…) et tu as perdu 10 megas par process avant de recycler, fais 4 requetes par keep-alive (la moyenne sur la plupart des serveur est bien au dessus de 4) et t’as perdu 40 megs par process. Une leak peut toujours etre un GROS probleme et ce systeme ne le camouflera pas, ca l’empechera juste de tout fouttre en l’air. J’ai passe 1 an de ma carriere a ecrire un module apache sous linux, j’ai une vague idee de comment ca marche, c’etait pas une attaque contre Apache et d’autre implementations ont d’autre problemes qui sont pris en compte de differente maniere…
Et SI un process systeme est toujours TRES lourd. Linux ou pas, pfff. Ce genre de pseudo debat est d’un ridicule, c’est n’importe quoi. Si encore on parlait des merites des differences d’implementation POSIX et process lourd entre le kernel linux et win, ca aurait un interet, on pourrait apprendre des trucs…
Ca doit d’ailleurs surement etre parcequ’un process ca coute si peu sous linux que Apache 2 est multi threade et que c’est ce changement architectural majeur qui fait passer la version de 1.x a 2.x. Je cite:
The original reason for creating Apache 2.0 was scalability, and the first solution was a hybrid web server; one that has both processes and threads. This solution provides the reliability that comes with not having everything in one process, combined with the scalability that threads provide.
C’est tellement leger que parfois, meme les threads sont consideres trop lourds et qu’on invente des concepts tels que les « fibers » (que pas mal de programmeurs connaissent pas encore). Les bases de donnes a haut volume fonctionnent pas mal sur de tels concepts. Chaque solution a ses avantages et ses inconvenients, process, threads, fibers ainsi que chaque implementation de chacun de ces concepts sur les differents OS a ses avantages et ses inconvenients. Qui sont, en plus, indissociables de l’implementation du scheduler. Autrement dit, avant de pouvoir en discuter serieusement il y a beaucoup de chose a apprendre et etonnament des gens qui savent, j’en ai pas vu un seul troller en terme tranches sur telle ou telle autre implementation serieuse. Resumer ca a une sorte de « machin roulaize, trop balaise, parceque X », c’est du concour de grosse bite qui apprend rien a personne.