> Si il etait developpe dans un soucis constant de velocite, ca serait pas un soft monothread...
Le fait est qu'il exploite le système d'entrée/sortie non bloquant des système Unix pour délivrer des fichiers de manière concurentielle quand les données sont disposées à être reçues et envoyées. En exploitant cela, il n'y a aucun temps mort dû à l'attente d'un condition propice à l'envoi (le destinataire n'a pas acquité la réception) ou à la réception (les données sont lues et prêts à envoyer).
Il est sûrement possible d'en améliorer les perfomances en utilisant les threads, mais ce que je voulais plutôt signaler, c'est que le rapport perfomance/légèreté est excellent. Sans la complexité des threads ou des processus multiples, ce serveur Web accomplit des performances plus qu'honorables. En fait, pour le contenu statique, et pour les tests sommaires que j'ai pu faire par curiosité, j'ai constaté par moi même que pour la délivrance de contenu statique, il n'a rien à envier à Apache 2.0 allégé (qui utilise un design hybride multi-thread/multi-processus), et cela dans les même conditions d'exploitations sur la même machine.
Par ailleurs, si les threads résolvaient vraiment tous les problèmes de performance, je pense que ça se saurait. Sans compter, dans les conditions réelles d'exploitation, la bande passante serait saturée bien avant que le design de ce serveur montre ses éventuelles faiblesses.
> Le design de ce soft est clairement mauvais niveau recherche de perf.
Je suis intéressé par tes arguments : si tu peux m'en dire plus, je suis preneur.
[^] # Re: Sortie du serveur Web THTTPD 2.25
Posté par kapouik . En réponse au journal Sortie du serveur Web THTTPD 2.25. Évalué à 3.
Le fait est qu'il exploite le système d'entrée/sortie non bloquant des système Unix pour délivrer des fichiers de manière concurentielle quand les données sont disposées à être reçues et envoyées. En exploitant cela, il n'y a aucun temps mort dû à l'attente d'un condition propice à l'envoi (le destinataire n'a pas acquité la réception) ou à la réception (les données sont lues et prêts à envoyer).
Il est sûrement possible d'en améliorer les perfomances en utilisant les threads, mais ce que je voulais plutôt signaler, c'est que le rapport perfomance/légèreté est excellent. Sans la complexité des threads ou des processus multiples, ce serveur Web accomplit des performances plus qu'honorables. En fait, pour le contenu statique, et pour les tests sommaires que j'ai pu faire par curiosité, j'ai constaté par moi même que pour la délivrance de contenu statique, il n'a rien à envier à Apache 2.0 allégé (qui utilise un design hybride multi-thread/multi-processus), et cela dans les même conditions d'exploitations sur la même machine.
Par ailleurs, si les threads résolvaient vraiment tous les problèmes de performance, je pense que ça se saurait. Sans compter, dans les conditions réelles d'exploitation, la bande passante serait saturée bien avant que le design de ce serveur montre ses éventuelles faiblesses.
> Le design de ce soft est clairement mauvais niveau recherche de perf.
Je suis intéressé par tes arguments : si tu peux m'en dire plus, je suis preneur.