Le serveur WEB le plus rapide du monde

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
2
fév.
2001
Noyau
Souvenez-vous... Il y a quelques mois, Ingo Molnar et Michael Johnson annoncaient la première version de TUX, un serveur web intégré au noyau Linux, dont les performances écrasaient tout ce qui avait été réalisé jusqu'alors (y compris Zeus) .
Le projet n'a pas été abandonné et son développement a au contraire été très actif. Aujourd'hui vient de sortir TUX 2.0. Encore plus rapide que son prédécesseur (avec encore moins de recopies de mémoire), il ajoute des fonctionnalités pour le moins intéressantes : meilleure stabilité, support pour un nombre infini de domaines virtuels et les CGI peuvent être individuellement assignés à tel ou tel processeur sur les systèmes SMP.
Une solution idéale pour les hébergeurs et ceux qui veulent réduire considérablement la charge de leur machine.

Note du modérateur: Et l'url ? :-)

Aller plus loin

  • # url

    Posté par  . Évalué à 1.

    Ca a l'air d'etre l'url officielle:
    http://www.redhat.com/products/software/ecommerce/tux/(...)
    Pas grand chose sur le site.
  • # url --->Redhat

    Posté par  . Évalué à -1.

    vive le RPM :-)
    Ils sont ou les tar.gz ???
  • # URL

    Posté par  . Évalué à 1.

    Gloups, il me semblait pourtant bien avoir inclu l'URL dans la news.

    Enfin, la voici :

    ftp://ftp.redhat.com/pub/redhat/tux/tux-2.0/(...)
  • # Bonne approche ?

    Posté par  . Évalué à 1.

    C'est cool de battre tout le monde en perf de cette maniere, mais je ne suis pas sur que mettre un serveur web dans le kernel soit une idee tres lumineuse du point de vue conceptuel.
    On avait le micro-kernel, puis le kernel monolithique, comment on va appeler celui-la ? macrokernel ?

    Je me demandes comment ils vont faire pour suivre l'evolution du kernel avec ca dedans car je doutes que Torvalds apprecie d'avoir un serveur web dans le kernel.

    A quand Quake3 dans le kernel ? Je suis sur qu'on pourrait gagner un certain nombre de frames de cette maniere.
    • [^] # Re: Bonne approche ?

      Posté par  . Évalué à 0.

      chacun compile son noyau comme il l'entend.
      pour une machine qui ne sert que de serveur web, ça ne parait pas idiot.

      aucun machine ne sert qu'à jouer à quake, non ? Si c'est le cas, une intégration dans le noyau ne serait pas idiote.
      • [^] # Re: Bonne approche ?

        Posté par  . Évalué à 1.

        Ben d'un point de vue pratique pour l'utilisateur, oui c'est utile et benefique d'un point de vue perf.

        Par contre pour les developpeurs, ca revient a avoir un fork du noyau, il faut maintenir les 2 versions en parralele, quand une modif arrive dans le kernel officiel il faut voir si ca n'impacte pas Tux, et si oui, ben il faut modifier Tux pour gerer ca,... c'est vachement dur a maintenir un truc pareil.

        Pour moi c'est comme si les roues d'une voiture etaient partie integrante du vehicule, ca permet des optimisations mais tu y perds en flexibilite et maintenance.
    • [^] # Re: Bonne approche ?

      Posté par  (site web personnel) . Évalué à 1.

      Arrete un peu de critiquer n'importe quoi, on va finir par croire que tu es un équipe de marketing qui essaie de vendre en direct chez la concurence.
      Tu vois vraiment le mal partout, essaie de faire un compliment. Regarde, je fait en faire des SINCERES : Windows a une belle interface graphique, il a l'avantage d'avoir beaucoup plus de jeux que Linux. C'est tout, je ne trouves plus.

      > On avait le micro-kernel, puis le kernel monolithique, comment on va appeler celui-la ? macrokernel ?

      Si je me souviens bien, au démarrage, le noyau de win2000 fait 17mo, je suis d'accord que l'on appelle linux un macro kernel quand il sera aussi boulimique. Petite astuce, tu peut recompiler le noyau.

      > A quand Quake3 dans le kernel ?

      Il n'est pas libre. :-)

      Plus je te lis et plus j'ai l'impression de voir un gosse qui poste, dés qu'il y a un domaine dans lequel vous n'étes plus leader(a cause de linux ou pas), tu arrrives et tu dit sans en avoir l'air que c'est de la merde pour une raison ou pour une autre. T'es vraiment un bon lanceur de troll, bravo.
      • [^] # Re: Bonne approche ?

        Posté par  . Évalué à 1.

        C'est pas linux que je critique, c'est l'approche de Redhat.
        Et je cause d'un point de vue conceptuel pas pratique.

        Ca n'a rien a voir avec une concurrence MS<->Linux, simplement qu'a mon avis un kernel ca sert a remplir les fonctions de BASE d'un OS, il faut pas tout mettre dedans, ca veut pas dire que ca marchera moins bien, mais d'un point de vue conceptuel c'est pas beau. Pour moi c'est comme ecrire un soft au kilometre plutot que faire des modules separes, c'est conceptuellement pas beau, mais ca peut tout a fait marcher aussi bien voire mieux que la version modulaire.

        Sinon, kernel32.dll fait 715Ko, c'est dans C:\winnt\system32\
        • [^] # Re: Bonne approche ?

          Posté par  . Évalué à 1.

          Oups la honte :+)

          J'ai melange kernel32.dll et ntoskrnl.exe :+)

          ntoskrnl.exe fait 674Ko.

          Ben oui les dev MS sont tellement betes qu'ils melangent le kernel avec une lib :+)
          • [^] # Re: Bonne approche ?

            Posté par  (site web personnel) . Évalué à 1.

            Tu compare les tailles d'un noyau monolitique et d'un micro-noyau la...

            (Enfin... Je suppose que les fichiers que tu cite correspondent au micro-noyau de NT)
        • [^] # Re: Bonne approche ?

          Posté par  . Évalué à 1.

          Sur ce point, je suis d'accord, c'est pour ça que je m'essaye le HURD (je sais tout le monde s'en fout ;)
          • [^] # Re: Bonne approche ?

            Posté par  . Évalué à 0.

            ouais, ben moi j'ai pas réussi à l'installer.
          • [^] # Re: Bonne approche ?

            Posté par  . Évalué à 1.

            et qu'apres tu nous racontes tes deboires sur #linuxfr :)
          • [^] # Re: vive les micro noyaux

            Posté par  . Évalué à 1.

            Tout a fait raison. Bientot on ne pourra plus faire tourner linux sur une petite config car il souffrira de boulimie.
            Il faut savoir s'arrêter. En cela HURD et QNX sont vraiment bien, car il y a modularité et souplesse.
            • [^] # Re: vive les micro noyaux

              Posté par  (site web personnel) . Évalué à 1.

              C'est un peu parler vite quand même !
              Je te signale au passage que le 2.4 occupe plutôt moins de mémoire et est plus rapide que le 2.2.
              Quel OS peut en dire autant ?

              Il y a le choix c'est tout : si on veut de la perf, on compile dans le noyau le serveur ouaib, sinon, on se garde un chtit noyau de derrière les fagots :)
              Quel OS peut en dire autant ? :)
              Désolé pour la redite ;)
        • [^] # Re: Bonne approche ?

          Posté par  . Évalué à 0.

          Hello,
          Linus a toujours dit qu'apache ne fonctionnait pas correctement et qu'il serait nécessaire d'intégrer des fonctions de serveur Web au noyau pour permettre des temps de réponse plus important pour les sites statiques, apache prendrait le relais pour les sites plus complexes.
          Source : Tribune du Libre 1999

          PS : je ne suis pas informaticien mais fait un métier que vous détestez le marketing ;-)
    • [^] # Re: Bonne approche ?

      Posté par  . Évalué à 0.

      Halte la petit gars.

      Tu ne t'interesse pas vraiment au noyau.
      Deja dans le noyau 2.4 se trouve khttp, qui lui meme sera remplacé par Tux. Docn tu vois Torvald n'a rien contre.

      Conceptuellement c'est nullement une erreur, une app qui tourne dans l'user space tout en diminant les acces de temps de recopie memoire dans le kernel space ne peut etre que bon.

      Et puis Quake 3 sans DRI tu fait combien de FPS
      • [^] # Re: Bonne approche ?

        Posté par  . Évalué à 1.

        Ah ben il est peut-etre d'accord d'integrer Tux dans le kernel alors, mais moi je trouve pas ca tres beau.
        C'est comme integrer completement XFree dans le kernel, ca accelererait les perfs mais tout mettre dans le kernel n'est pas la bonne chose a faire.

        Pour moi tout ce qui a trait a la gestion de l'OS doit se trouver dans le kernel et rien d'autre, les applications n'ont rien a faire dans le kernel space.
        • [^] # Re: Bonne approche ?

          Posté par  . Évalué à 0.

          Je suis pas sûr, mais il me semble que dans NT 4 tout le sous-système de gestion de l'interface graphique est incorporé au niveau noyau, non ??? ou je me trompe complètement ???
          Il me semble bien que dans la série des NT 3.x il ny était pas mais qu'en l'incorporant dans le noyau, le système gagnait en performance .
          • [^] # Re: Bonne approche ?

            Posté par  . Évalué à 0.

            >il me semble que dans NT 4 tout le sous-système de gestion de l'interface graphique est incorporé au niveau noyau, non ?

            Je confirme. Ca a d'ailleurs fait tout un foin. Et c'est une des raisons de l'instabilité du bazar !
      • [^] # Re: Bonne approche ?

        Posté par  . Évalué à 0.

        >> Et puis Quake 3 sans DRI tu fait combien de FPS
        150
      • [^] # Re: Bonne approche ?

        Posté par  . Évalué à 0.

        juste une remarque.... en integrant un serveur web dans le kernel, ca revient a integrer de l'applicatif au niveau systeme.... donc en gros c faire la meme connerie que Microsoft avec Windows.

        Pourquoi croyez vous que quand word plante, windows plante aussi une fois sur deux????
    • [^] # Re: Bonne approche ?

      Posté par  . Évalué à 0.

      Moi je suis tout a fait d'accord avec PasBill PasGates. Qu'est ce que c'est que ce principe de macrokernel la.... Niveau securité, il doit y avoir de ces trous......
  • # perfs

    Posté par  . Évalué à 0.

    Il me semblait avoir lu qu'au contraire les perfs de ce serveur-noyau était loin d'être formidables de manière globale, tout en étant il est vrai imbattable sur certaines tâches bien spécifiques.
    Mais je me trompe peut-être...
    Qui est-ce qui nous fait un petit résumé des messages de la LKML sur le sujet ? :D

    Au passage je crois bien que Linus est un des premiers supporters de ce truc-là.
    Mais c'est vrai qu'après les serveur NFS et Web, pourquoi pas une BD-noyau :)
    • [^] # Re: perfs

      Posté par  . Évalué à 1.

      Non le problème des performances concernait khttpd (l'actuel serveur web du noyau, livré en standard depuis les 2.3) qui se faisait battre par BOA pour les pages statiques.
      Un patch (en fait deux, le premier n'était pas bon) pour gérer le keepalive a été posté, et du coup le khttpd se révélait plus rapide, mais avec un temps de latence plus long.

      Deux remarques cependant :

      - BOA est vraiment destiné aux pages statiques et aux simples scripts CGI, il ne sait pas s'interfacer avec PHP par exemple, sans passer par l'interface CGI.
      - Utiliser khttpd en combinaison avec un autre serveur (apache, roxen, thttpd, zeus...) n'est pas idiot, et contribue à réduire un peu la charge de la machine et l'occupation de la mémoire. On lance le serveur web sur un port alternative, comme 8080, et ktthpd sur le port 80. Quand il ne sait pas faire (ex: CGI, PHP, Perl...) il agit comme un petit proxy et passe la requete à l'autre serveur web.

      Cela dit TUX est nettement plus performant et configurable, que ce soit pour les CGI ou les pages statiques.
    • [^] # Re: perfs

      Posté par  . Évalué à 1.

      Non le problème des performances concernait khttpd (l'actuel serveur web du noyau, livré en standard depuis les 2.3) qui se faisait battre par BOA pour les pages statiques.
      Un patch (en fait deux, le premier n'était pas bon) pour gérer le keepalive a été posté, et du coup le khttpd se révélait plus rapide, mais avec un temps de latence plus long.

      Deux remarques cependant :

      - BOA est vraiment destiné aux pages statiques et aux simples scripts CGI, il ne sait pas s'interfacer avec PHP par exemple, sans passer par l'interface CGI.
      - Utiliser khttpd en combinaison avec un autre serveur (apache, roxen, thttpd, zeus...) n'est pas idiot, et contribue à réduire un peu la charge de la machine et l'occupation de la mémoire. On lance le serveur web sur un port alternative, comme 8080, et ktthpd sur le port 80. Quand il ne sait pas faire (ex: CGI, PHP, Perl...) il agit comme un petit proxy et passe la requete à l'autre serveur web.

      Cela dit TUX est nettement plus performant et configurable, que ce soit pour les CGI ou les pages statiques.
  • # Question ???

    Posté par  . Évalué à 1.

    Ca excecute les scripts php ou pas ?
    • [^] # Re: Question ???

      Posté par  . Évalué à -1.

      De toutes façons le PHP ça vaut rien par rapport au Perl...

      --
      bmc qui avait envie de troller
    • [^] # Re: Question ???

      Posté par  . Évalué à 1.

      hélas non... mais en fait, pas hélas parce qu'un noyeau qui prends 12Mo en mem, c'est moyen ;)
      • [^] # Re: Question ???

        Posté par  . Évalué à 1.

        Ca peut exécuter du php... disons que comme khttpd, quand TUX sait pas faire quelque chose, il peut passer la main à un autre serveur.
        • [^] # Re: Question ???

          Posté par  . Évalué à 1.

          c'est sur, si tu détournes ;op
  • # OK, mais à quoi ça sert ?

    Posté par  . Évalué à 0.

    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, ...).
    • [^] # Re: OK, mais à quoi ça sert ?

      Posté par  . É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.

      Tux intègre un cache générique pour toutes les requêtes vers des pages dynamiques, à la difference de BOA et kHttpd.

      Les tests ou TUX explose la concurence intègrent la génération de pages dynamiques.

      Tux est en réalité un framework pour des applications kernel-land -> kernel-land (eg servir un fichier vers le reseau par http, smb, ftp)... des plugins pour faire du SMB ont été annoncés.

      Plutot que de vociferer sur RedHat, interessez-vous aux developpeurs qui sont derriere tout ca et qui eux ont de réels arguments à défendre.

Suivre le flux des commentaires

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