Journal Sortie du serveur Web THTTPD 2.25

Posté par .
Tags : aucun
2
20
déc.
2003
La version 2.25 du serveur Web THTTPD vient de sortir. THTTPD est un serveur Web totalement différent de Apache. Il est beaucoup plus léger car il repose sur un design totalement différent (notament, il ne forke pas à chaque requête initiale pour un client donné). Très sécurisé et développé dans un soucis constant de vélocité, il est réellement un serveur Web novateur qui tien ses promesses !

THTTPD est très adapté à la délivrance de contenu statique tel que des pages HTML ou des images. D'ailleurs, de nombreux site utilisent Apache pour les pages dynamiques et THPPTD pour les images ou les contenus statiques. En effet, les pages dynamiques avec THTTPD ne sont disponibles qu'en CGI, bien qu'il existe la possibilité d'avoir un module PHP pour les versions antérieures (avec un plus ou moins de "bidouillage").

Une des caratéristiques intéressantes de THTTPD est la possibilité de contrôler de manière simple et efficace le partage de la bande passante et son utilisation maximale.

Une autre fonctionnalité (controversée) que de nombreuses personnes trouvent tout aussi intéresssante, est le contrôle d'accès par referrer local, pour éviter par exemple qu'une image de votre cru soit diffusée sur une page distante sans héberger l'image, mais en utilisant celle qui est sur votre machine et consommant ainsi votre bande passante, tout en dénaturant le contexte de diffusion de votre travail.

À noter que THTTPD est le serveur Web idéal pour les machines personnelles ne diffusant que du contenu statique via une connection ADSL : le contrôle de la bande passante y trouve tout son sens. Il est aussi possible d'utiliser THTTPD pour les pages statiques en même temps que Apache qui servira à délivrer les contenus dynamiques (en attendant que le module PHP pour THTTPD arrive).

Enfin, THTTPD est très facilement configurable et sa page de manuel est non seulement très à jour, mais elle suffit à la configuration du serveur (bien évidemment, il faut connaître le fonctionnement d'un serveur Web).

- Accueil : http://www.acme.com/software/thttpd/(...)
- Sources : http://www.acme.com/software/thttpd/thttpd-2.25.tar.gz(...)
- Changements : http://www.acme.com/software/thttpd/#releasenotes(...)
  • # Re: Sortie du serveur Web THTTPD 2.25

    Posté par . Évalué à 2.

    Euh...

    Si il etait developpe dans un soucis constant de velocite, ca serait pas un soft monothread...

    Le design de ce soft est clairement mauvais niveau recherche de perf.
    • [^] # Re: Sortie du serveur Web THTTPD 2.25

      Posté par . Évalué à 3.

      Apparemment thttpd est basé sur select ce qui (si c'est bien géré) ne pose pas de problème de perf du moment qu'on diffuse des données statiques, pour les pages dynamiques là c'est à voir: il semble bien gérer les CGI mais il manque une comparaison avec apache + mod_php.
      • [^] # Re: Sortie du serveur Web THTTPD 2.25

        Posté par . Évalué à 3.

        Ben met ce soft sur un quadri-cpu et il va plafonner a 25% de la puissance du serveur au grand maximum.

        Met ce soft sur un serveur charge et on verra comment il gerera le fait qu'il ne peut rien faire pendant qu'il attend sur certaines operations.

        Utiliser des I/O non bloquants c'est bien, mais c'est loin d'etre suffisant pour avoir un soft performant, un thread pool c'est aussi une bonne idee quand tu veux monter en charge.
        • [^] # Re: Sortie du serveur Web THTTPD 2.25

          Posté par (page perso) . Évalué à 4.

          personne n'a dit qu'i était optimisé pour les machines multi-procs...

          Met ce soft sur un serveur charge et on verra comment il gerera le fait qu'il ne peut rien faire pendant qu'il attend sur certaines operations.
          => La primitive select n'est pas nécessairement bloquante, tu peux l'utiliser pour surveiller un lot de descripteurs (sockets, fichiers, etc....) et savoir s'ils ont changé d'état.....

          Utiliser des I/O non bloquants c'est bien, mais c'est loin d'etre suffisant pour avoir un soft performant, un thread pool c'est aussi une bonne idee quand tu veux monter en charge
          => ben ça dépend, en mutli-thread tu as tous les changement de contexte & Co, les calculs de ce que le SE doit dupliquer ou pas.... et puis il faut gérer la mémoire partagé et l'exclusion mutuelle sur les données utilisées en commun alors tout est relatif.... mais dans l'autre sens c'est vrai aussi que tu augmentes la zone de code et la pagination...

          il faudrait des benchs de ce soft avec apache/caudium/autres serveurs web par exemple (dans le cadre d'une utilisation monoproc)

          voilà, voilà


          M.
    • [^] # Re: Sortie du serveur Web THTTPD 2.25

      Posté par . Évalué à 3.

      > 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 . Évalué à 1.

        Il lui manque clairement un thread pool pour pouvoir tirer parti des serveurs SMP et pouvoir utiliser le CPU pendant certains appels qui demandent une attente quelconque.

        Les threads ne resolvent pas tous les probs de performance, mais c'est assez essentiel si tu veux que ton soft vale qqe chose sur un serveur SMP

        Bref, il a probablement des perfs valables sur une machine mono-CPU, mais ca s'arrete la, j'ai du mal a appeler ca un design oriente performance.
        • [^] # Re: Sortie du serveur Web THTTPD 2.25

          Posté par (page perso) . Évalué à 3.

          Sur l'ensemble des serveurs web la planète, je ne connais pas le pourcentage de serveur mono ou multi cpus mais cela serait intéressant....

          Si au moins 5 à10% de ces serveurs sont uni-cpu alors je pense que ce soft à sa place....

          M.
          • [^] # Re: Sortie du serveur Web THTTPD 2.25

            Posté par . Évalué à 1.

            Avec la generalisation des Pentium 4 équipé de l'Hyperthreading, je ne suis pas sur car méme si c'est un peut gagdget au debut je ne connais pas grand monde qui soit pret a cracher sur un petit gain de 5-15% de perfs.
        • [^] # Re: Sortie du serveur Web THTTPD 2.25

          Posté par . Évalué à 2.

          > Il lui manque clairement un thread pool pour pouvoir tirer parti des serveurs SMP

          C'est tout à fait possible, personnellement je n'ai aucune expérience de programmation pour architecture SMP. D'ailleurs, je pensais (à tort ?) que c'était le rôle du système d'exploitation de répartir de manière transparente les instructions d'exécution d'un processus entre les processeurs.

          > (...) pouvoir utiliser le CPU pendant certains appels qui demandent une attente quelconque.

          Justement, les temps morts des entrées/sorties sont éliminés par l'architecture de THTTPD. C'est d'ailleurs un de ces points forts à ce jour : tirer parti de l'architecture des systèmes Unix pour les entrées/sortie non-bloquants.

          > Les threads ne resolvent pas tous les probs de performance, mais c'est assez essentiel si tu veux que ton soft vale qqe chose sur un serveur SMP. Bref, il a probablement des perfs valables sur une machine mono-CPU, mais ca s'arrete la, j'ai du mal a appeler ca un design oriente performance.

          Pour ce qui concerne la haute performance à tout prix, c'est possible qu'il ne soit pas une "killer app" sur machine SMP. Mais c'est relatif : n'ayant pas de machine SMP, je l'ai plutôt recommandé pour une machine personnelle sur laquelle j'ai bien vu la différence avec Apache pour les contenus statiques. Si j'avais une machine SMP sous la main, j'aurais pu donner un avis, mais là, ce n'est malheureusement pas le cas. Ceci dit, si tu as une machine SMP à m'offrir pour que je m'initie aux systèmes SMP, je suis preneur :)
          • [^] # Re: Sortie du serveur Web THTTPD 2.25

            Posté par . Évalué à 1.

            C'est tout à fait possible, personnellement je n'ai aucune expérience de programmation pour architecture SMP. D'ailleurs, je pensais (à tort ?) que c'était le rôle du système d'exploitation de répartir de manière transparente les instructions d'exécution d'un processus entre les processeurs.

            L'OS ne peut pas repartir les instructions d'un processus sur plusieur processeur (il va pas s'amuser a deassembler le processus pour repartir les routines, il a déjà assez de boulot comme cela l'OS :-), mais il peut repartir des processus et de thread entre plusieur processeur.
            Donc si ton programme n'utilise ni de Fork ni de thread, ton architecture SMP, va étre cruellement sous exploitée.

            Pour ce qui concerne la haute performance à tout prix, c'est possible qu'il ne soit pas une "killer app" sur machine SMP. Mais c'est relatif : n'ayant pas de machine SMP, je l'ai plutôt recommandé pour une machine personnelle sur laquelle j'ai bien vu la différence avec Apache pour les contenus statiques. Si j'avais une machine SMP sous la main, j'aurais pu donner un avis, mais là, ce n'est malheureusement pas le cas. Ceci dit, si tu as une machine SMP à m'offrir pour que je m'initie aux systèmes SMP, je suis preneur :)

            Tu peux pas mettre la main sur un P4C ? la difference est pas aussi flagrente que sur un systeme SMP, mais elle est visible.
        • [^] # Re: Sortie du serveur Web THTTPD 2.25

          Posté par (page perso) . Évalué à 1.

          > Bref, il a probablement des perfs valables sur une machine mono-CPU, mais ca s'arrete la,

          Bah, ça dépends. Si tu fais tourner plusieurs serveurs services sur la même machine (genre un truc à base de chroot, ou de virtualisation comme c'est le cas sur linuxfr, ou tout simplement une machine qui fait serveur web et serveur de base de donnée en même temps), ça peut être intéressant d'avoir un serveur qui de toute façon ne t'aurais pas bouffé plus d'un CPU le plus efficace possible.

          Tu peux très bien imaginer une machine 8 procs avec 10 serveurs virtuels faisant tourner la bête, et là, ca peut être intéressant.

          Maintenant, pour une solution générale, 100% d'accord avec toi.
    • [^] # Re: Sortie du serveur Web THTTPD 2.25

      Posté par (page perso) . Évalué à 1.

      Faut pas pousser non plus, sur un monoprocesseur, il a de très bonnes perfs. Et comme je ne vois pas de serveur quadri processeur chez moi, je trouve le principe du select() très bien. On ne peut pas trouver de meilleures performances dans l'absolu, mais dans la situation qui m'intéresse (machine mono proc un peu vieille servant des pages statiques), c'est un bon choix.

      D'ailleurs, il y a des benchs sur le site de thttpd qui montrent les bonnes perfs des serveurs monothreads :
      http://www.acme.com/software/thttpd/benchmarks.html(...)
      Et clairement les designs utilisant les threads ont de moins bonnes perfs sur un mono processeur.
      On pourrait penser que comme c'est sur leur site ils favorisent leur propre serveur, mais j'ai pu reproduire des résultats similaires sur une page statique sur archi i386 en testant apache vs thttpd vs mathopd vs awhttpd (ce dernier n'est pas dans le bench donné en lien, mais il est monothread basé sur select() et se place au meme niveau que thttpd/mathopd).
    • [^] # Re: Sortie du serveur Web THTTPD 2.25

      Posté par . Évalué à 3.

      Tu devrais organiser des séminaires dans ta boite, pour expliquer aux gens comment faire des softs performants.
  • # Re: Sortie du serveur Web THTTPD 2.25

    Posté par . Évalué à 4.

    Le débat "c'est monothread donc nul" ne m'interessant pas, je vais me contenter de donner l'URL d'un utilisateur connu qui semble tenir la charge :)

    http://ftp.club-internet.fr/(...)

    M
    • [^] # Re: Sortie du serveur Web THTTPD 2.25

      Posté par (page perso) . Évalué à 4.

      pour ceux qui n'aurais pas compris :

      allez ici http://ftp.club-internet.fr/marchepas(...) et regardez le texte en bleu ou affichier la source........

      M.
    • [^] # Re: Sortie du serveur Web THTTPD 2.25

      Posté par (page perso) . Évalué à 1.

      Oui, mais là, c'est un cas facile : c'est un serveur de pages statiques.

      Tu met un cluster de machine mono-processeur éventuellement bas de gamme, et un routeur http à l'entrée qui réparti les requêtes.

      Maintenant, fait la même chose avec des pages dynamiques, suivi de session par utilisateur, là, tu ne peut plus traiter les requettes indépendament, et c'est là que les gros serveurs multi-pro peuvent être utiles.
  • # Re: Sortie du serveur Web THTTPD 2.25

    Posté par . Évalué à 0.

    notament, il ne forke pas à chaque requête initiale pour un client donné

    jolie tentative mais apache a corrigé ça !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.