Apache 2.0 disponible pour tous

Posté par  . Modéré par Yann Kerhervé.
Étiquettes :
0
6
avr.
2002
Internet
Apache 2.0.35 est enfin sorti. Comme son nom ne l'indique pas, il s'agit de la première sortie officielle du serveur web numéro 1 (en version 2.x).

Parmi les nouveautés, le fait qu'il fonctionne maintenant dans un mode mélant les threads et les processus afin d'avoir une meilleure montée en charge.

Il reste maintenant à voir les effets de cette sortie sur les statistiques d'utilisation de netcraft, ou apache est sur une pente plutot descendante depuis 9 mois environ.

(ndm : c'est la fête \o/)

Aller plus loin

  • # changement majeur...

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

    C'est un changement majeur dans le paysage du web... Beaucoup de projets (mod_perl2, subversion : http://subversion.tigris.org(...) , ...) dépendaient de cette sortie.
    Il va falloir un peu de temps avant que tout le monde migre :)

    On risque de voir également beaucoup de apache2 dans les survey netcraft... mais qui ne tournent pas sous unix. En effet, un des plus gros gagnant est windows qui pourra bénéficier du mode threadé...

  • # Ca y est!!

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

    Enfin, ca y est, apache 2.0!

    Quel soulagement. Personnellement, je l attendais avec impatience pour pouvoir profiter du multithread. En effet, cela permet des applications plutot sympa, tel ircg (http://www.schumann.cx/ircg/(...) ), cette bibliotheque php qui permet d interfacer de l irc. Malheureusement, un support multithread etait necessaire sur le serveur http, ce qui obligeait a se tourner vers d autres serveurs (tels thttpd). L integration au sein d un environnement de production melant un apache traditionnel n etait pas aisee.

    Pour une bonne nouvelle...

  • # Statistiques...

    Posté par  . Évalué à 10.

    Pas plus tard que ce matin, j'observais encore les statistiques sur netcraft et je m'inquiétait de la progression de IIS par rapport à apache.

    Vu que je n'étais pas du tout au courant de la sortie d'une version 2 d'apache, j'accueille cette nouvelle avec grand plaisir.

    Quelqu'un pourrait m'expliquer concrètement les avantages du multithread et comment ça fonctionne ?

    Il y a plein de bonnes nouvelles en ce moment. Je trouve qu'il y a pas mal de mouvements dans le monde du libre et ça traduit une bonne santée. Je suis confiant pour l'avenir :-)

    • [^] # Re: Statistiques...

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

      Avant, apache fonctionnait avec des appels à fork() lorsque le serveur répondait à plusieurs clients en même temps, ce qui avait pour conséquence de créer ce que l'on appelle un processus «lourd», c'est à dire indépendant des autres. Dorénavant, les processus seront des threads, des processus légers (ce qui signifie, partage des variables entre autres, non duplication des données...)
      En gros, le temps CPU pour créer un processus «lourd» est théoriquement plus important que pour créer un processus «léger», donc le serveur sera plus rapide :)
      Le seul problème des processus légers, c'est que c'est plus compliqué à débugger car tout fonctionne avec les mêmes données, donc utilisation de système des protections exclusif des données... etc...

      • [^] # Re: Statistiques...

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

        et surtout ne pas oublier que le fork() n'existe pas en tant que tel sous Windows...

        Il en existe une émulation avec cygwin... mais pas en windows natif.

        Par contre, les threads sont gérés par windows nativement.

        --
        Je sais, on est sur linuxfr et on ne parle pas de windows...

        • [^] # Re: Statistiques...

          Posté par  . Évalué à 10.

          En effet fork n'existe pas mais la fonction CreateProcess existe,(http://www.leb.net/wine/WinDoc/msdn/sdk/platforms/doc/sdk/win32/fun(...))

          Par ailleurs, fork est tres archaique et tres lourd, puisqu'il duplique l'ensemble de la memoire et des descripteurs de fichiers ouverts.
          Fork est parfois aussi thread non safe comme sous solaris.

          Par contre qqchose que je n'ai toujours pas compris sous linux, c'est que apres la fonction pthread-create sous linux qui cree un thread, On voit dans le top un nouveau processus ... Est ce un leure ou ca cree vraiment un process ? Y a t il une autre maniere de creer un thread sous linux ?

          • [^] # Re: Statistiques...

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

            Oui, mais il y a une grande différence entre le fork() de Unix et le CreateProcess() de Windows.

            fork() : création d'un nouveau processus en copiant l'environnement mémoire et le statut d'exécution du processus en cours (le père donc).

            CreateProcess : création d'un nouveau processus et de son thread attaché en exécutant un binaire.

            Donc dans le deuxième cas, on ne peut pas profiter directement du travail du processus père dans le processus fils (à part en passant par un fichier de stockage ou autre mécanisme système).

            Bref la fonction CreateProcess() de Windows est équivalente à exec*() de Unix.


            Après, pour ta question sur le pthread_create, pour moi c'est la création d'un nouveau thread et pas d'un processus (le man dit comme cela également).
            Mais faudrait peut-être vérifier.

            • [^] # Re: Statistiques...

              Posté par  . Évalué à 6.

              Oui je suis d'accord :) Exec passe par un fork de toute facon. Mais creer un processus a partir de soi n'a que peu d'interet par rapport au thread a part de charger un autre code => donc un autre executable.

              Par contre d'apres les tests que j'ai fait pour chaque thread que j'ai dans mon programme j'ai une entree identique dans le top avec un pid different, mais avec la meme taille memoire.
              C'est assez bizarre, j'ai cru lire que linuxthread utilise clone pour creer les threads, et fork utilise aussi clone...

              • [^] # Re: Statistiques...

                Posté par  . Évalué à 6.

                Clone est l'appel systeme de base pour creer des threads et des processus sous linux. Tu lui passes des flags pour dire ce que tu veux cloner et ce que tu veux partager (ex: partager espace d'adressage, partager fichier, ...).

                Je crois qu'il y a aussi un flag pour dire de partager le pid, mais que c'est (c'etait?) partiellement implemente. Bref clone c'est l'outil de base pour programmer avec les threads mais il n'est pas portable.

              • [^] # Re: Statistiques...

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

                Il y a deux types de thread utilisables sur les systemes unix: les thread 'kernel' et les thread 'users'.

                Comme le nom l'evoque les thread 'kernel' sont gerres par le noyau, sous linux il sont en effet tres semblables a des processus ce qui permet un ordonnancement simplifier du bazar, mais il ne faut pas s'y tromper les thread kernel partagent bel et bien leurs memoire avec leurs pere, la seule difference avec les processus et que l'ecriture sur des donnees partagees ne genere pas de copie desdites donnees.

                Il y a une autre possibilite pour faire du multi thread c les thread utilisateurs implementes par exemples via la lib gnu pth (portable thread) si je ne m'abuse. Dans ce cas on ne voit plus qu'un seul processus (vu qu'il n'y en a en fait q'un seul) celui ci faisant un ordonnancement au niveau utilisateurs pour chaqu'un de ses thread.

                Chaque solution a ses avantages et inconvenient je ne saurait pas dire quelle est la meilleure.

              • [^] # Re: Statistiques...

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

                Exec passe par un fork de toute facon

                Non, exec() et fork() sont deux appels indépendants. En général pour lancer un autre programme on fait un fork() suivi d'un exec() (ce que fait un shell qui lance une commande par exemple), mais il y a des cas ou on veut faire un exec() directement.

                Mais creer un processus a partir de soi n'a que peu d'interet par rapport au thread a part de charger un autre code => donc un autre executable.

                Non plus. Historiquement, les serveurs sous Unix fonctionnent comme ça. Un process père qui écoute en attente de connection, et à chaque connection il forke un fils qui la traite. C'est un peu plus lourd que des threads, mais plus facile à programmer et plus fiable.

                • [^] # Re: Statistiques...

                  Posté par  . Évalué à 1.

                  Oui pardon j'avais confondu exec et system ...

                  Je trouve les forks personnellement moins elegants que les threads, car il surcharge la machine mais aussi la table des process. Par contre c'est clairement plus fiable et plus facile a developper / debugger.
                  Par contre fork ne fait pas bon menage avec les threads sous solaris par exemple.

                  Enfin tout ca c'est une question de gout comme beaucoup de choses :)

          • [^] # Re: Statistiques...

            Posté par  . Évalué à 10.

            Du point de vue de Linux, un thread est un processus ordinaire qui partage son espace mémoire avec d'autres processus du même type.

            Linux crée donc un VRAI processus, ce qui est bien plus logique, ça évite beaucoup de ré-écriture, beaucoup de complexité, et ... beaucoup de bugs.

            Fork quand à lui, n'est pas si lourd que cela, parce qu'en réalité, pratiquement rien n'est dupliqué, le noyau fonctionne en mode 'copie sur écriture', la mémoire n'est dupliqué que lorsqu'il y a effectivement une écriture (qui fait que les données changent entre le père et le fils), et cette copie ne se fait que sur la page mémoire concernée (4Ko sur i386).

            La différence entre un processus et un thread n'est finalement pas vraiment au niveau des performances sous Linux, ça concerne plutôt la possibilité de partager de la mémoire. Avec des processus il faut passer par des mécanismes un peu lourd comme shm ou un socket, avec des threads c'est bien plus simple. En cas de bug, le modèle processus reste bien plus simple à gérer, on ne perturbe qu'un processus, avec les threads, on fait tomber tous les threads.

            Enfin Apache doit généralement être root pour pouvoir se binder sur le port 80, avec des processus, tous les serveurs qui répondent aux requêtes ne sont pas root, les exploits n'exposent que l'identité sous laquelle tourne le serveur. Avec les threads, on ne peut pas utiliser ce genre de solution.

        • [^] # Re: Statistiques...

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

          C un peu plus complique que ca:

          Windows gerre des processus qui contiennent au depart un thread. On peut recreer des processus mais pas de vraies copie du processus initial (sauf a executer le meme).
          Les threads sont des thread kernel.

          Mais il gerre aussi ce qu'ils appelent des fils (du singulier fil(ficelle)) qui sont en fait des thread utilisateur.

          Allez vous retrouver dans tout ce bordel j'vous dit pas. ET a cote de ca y a les dll qui interceptent les appels de creation de thread ds les processus qui les utilisent !

  • # On ne migre pas comme ça

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

    Si c'est bien un changelent majeur, j'imagine que la migration doit se faire ne douceur... Qu'en est-il des fichiers de conf longuement aiguisés ? Le fonctionnement change aussi, j'imagine... PHP ? les modules habituels Et sous winnt, la gestion des droits ?
    Finalement qu'est-ce u ça m'aporte ?
    Une {url] (en français de préférence) ?

    • [^] # Non, mais c'est pas pour ça que c'est dur...

      Posté par  . Évalué à 9.

      Allez, hop, il suffit de demander !

      http://httpd.apache.org/docs-2.0/upgrading.html(...)
      (en français si votre novigateur est configuré pour dire que de toutes les langues, c'est la ouate -euh pardon, le français- qu'il préfère)

      Cela dit, je suis d'accord sur le fait qu'on ne migre pas comme ça ; notamment, il y a le problème des modules externes, qui n'ont pas forcément été portés pour les versions 2.0.x . Mais pour un grand nombre de gens, une migration de 1.3.x vers 2.0.x devrait se faire en douceur, à condition de faire ça proprement... A commencer par ne pas faire ça sur un serveur d'exploit comme un barbare , càd sans avoir au moins testé les fonctions de base (i.e. qui servent le plus souvent dans ton environnement !) :)

      Donc, pour ce qui est de php et tout le bazar, il vaut mieux attendre encore un peu. Pas longtemps, si tu veux mon avis. En attendant, si l'upgrade te démange, tu peux toujours passer en 1.3.24 :)

  • # Overview of New Features in Apache 2.0

    Posté par  . Évalué à 10.

    A mon avis ce link aurait aussi sa place sous la news:

    http://httpd.apache.org/docs-2.0/new_features_2_0.html(...)

    (vu que le changelog indiqué dans l'annonce est pas particulierement utile ni parlant).

    happy compiling :)
    --Swix

  • # Migration vers apache 2.0 pour un hébergeur

    Posté par  . Évalué à 10.

    L'idéal serait d'avoir une compatibilité avec les anciens fichiers de conf, si possible (au moins pour les parties les plus lourdes : VirtualHost et Directory). Les autres parties (qui sont en fait la config de base) ne sont pas forcément très complexes à mettre à jour je pense. Mais pour un site professionnel (pour un hébergeur, au hasard), les parties "répétitives" devront clairement être compatibles.

    C'est d'ailleurs ce qui semble être le cas. La page "migrer vers Apache 2.0" (http://httpd.apache.org/docs-2.0/upgrading.html(...)) indique les modifs dans les fichiers de conf :

    _ CacheNegotiatedDocs remplacée par CacheNegotiatedDocs on|off
    _ ErrorDocument 403 "Some Message remplacé par ErrorDocument 403 "Some Message"
    _ AccessConfig et ResourceConfig à remplacer par Include
    _ BindAddress à remplacer par Listen
    _ <ServerType> n'existe plus

    Pour ces modifs, il suffit d'un simple grep ou sed sur les fichiers de conf et d'une petite modif de syntaxe dans les outils de création de fichiers de conf. Rien de grave de ce côté, donc.

    Plus gênant :

    _ ExtendedStatus n'existe plus. Dommage, certains hébergeurs s'en servent pour superviser leurs serveurs Web :o( L'air de rien, ça a un gros impact. En plus, la doc (http://httpd.apache.org/docs-2.0/mod/mod_status.html(...)) n'a pas été remise à jour... Là ça bloque !
    _ mod_log_agent et mod_log_referer sont remplacés par CustomLog. Esperons que résultat final puisse être identique afin de ne pas troubler les outils de stats déjà utilisés avec Apache 1.3 (souvent développés à la main par les hébergeurs).

    Ces deux dernières modifs risquent de retarder pas mal le déploiement d'Apache 2.0 chez les hébergeurs, et à mon avis, les stats NetCraft ne vont pas être boulversés dès demain.

Suivre le flux des commentaires

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