A part pour figurer à la première place des WebBenchs en pages statiques, ont peut quasi dire: à rien. Et pour cause, un simple apache (ou autre) ont déjà des débits en pages statiques énorme et peuvent supporter avec une machine suffisamment puissante la charge des sites les plus fréquentés sans problèmes.
Donc, on en revient toujours au problème des pages dynamiques. Le pire étant certainement les cgi en perl, modperl améliore ensuite les choses, php4 doit encore être meilleur, avec des solutions de cache c'est encore mieux.
Et pour finir, une solution adoptée par slashdot à l'époque ou ses scripts cgi ne suivaient plus: des scripts perls lancés quand la charge de la machine n'est pas trop élevée, placé dans des cron, et qui génèrent des pages html (comme ça apache délivre des pages statiques). Inconvénient: on a plus tout à fait du temps réél pour les pages, donc certains services d'un site ne peuvent pas se baser la dessus, mais une partie présentant des news (et générant en général la même page pour des milliers de visiteurs différents) y gagne beaucoup. Et rien n'interdit de mélanger les systèmes. Et si ça ne suffit toujours pas, on peut encore y gagner en écrivant les scripts en C, mais là il faudrait peut-être envisager la multiplication des serveurs avec un répartiteur de charge.
En conclusion, l'utilité réélle de ce genre de chose est douteuse, il faudrait faire attention à ne pas trop développer dans l'intégration des softs dans le noyau (car sur cette base, on peut facilement envisager des tas de services dont les performances pourraient être augmentées, au hasard, serveur ftp, dns, ...).
# OK, mais à quoi ça sert ?
Posté par Anonyme . En réponse à la dépêche Le serveur WEB le plus rapide du monde. Évalué à 0.
Donc, on en revient toujours au problème des pages dynamiques. Le pire étant certainement les cgi en perl, modperl améliore ensuite les choses, php4 doit encore être meilleur, avec des solutions de cache c'est encore mieux.
Et pour finir, une solution adoptée par slashdot à l'époque ou ses scripts cgi ne suivaient plus: des scripts perls lancés quand la charge de la machine n'est pas trop élevée, placé dans des cron, et qui génèrent des pages html (comme ça apache délivre des pages statiques). Inconvénient: on a plus tout à fait du temps réél pour les pages, donc certains services d'un site ne peuvent pas se baser la dessus, mais une partie présentant des news (et générant en général la même page pour des milliers de visiteurs différents) y gagne beaucoup. Et rien n'interdit de mélanger les systèmes. Et si ça ne suffit toujours pas, on peut encore y gagner en écrivant les scripts en C, mais là il faudrait peut-être envisager la multiplication des serveurs avec un répartiteur de charge.
En conclusion, l'utilité réélle de ce genre de chose est douteuse, il faudrait faire attention à ne pas trop développer dans l'intégration des softs dans le noyau (car sur cette base, on peut facilement envisager des tas de services dont les performances pourraient être augmentées, au hasard, serveur ftp, dns, ...).