[article] APACHE, comment ça marche ?

Discussion dans 'Administration d'un site Web' créé par fandecine, 28 Décembre 2007.

  1. fandecine
    fandecine WRInaute passionné
    Inscrit:
    2 Avril 2005
    Messages:
    1 886
    J'aime reçus:
    0
    Pour faire suite à la serie d'article que j'ai publié sur WRI et pour répondre aux MP que je reçois à ce sujet, je vais essayer aujourd'hui d'expliquer le fonctionnement d'un serveur WEB et plus précisement le plus célébre d'entre eux APACHE.

    Apache (sous Unix) est un serveur basé sur un modèle appelé pre-forking.

    Fork en Unix, est l'instruction qui permet de créer un nouveau processus par clonage, le pré signifie qu'apache crée un certain nombre de processus avant qu'ils ne soient nécessaire, en prévision d'une utilisation future.

    En d’autres termes, le processus père (c'est-à-dire celui qui est créé au lancement d’apache) n'est responsable que de la création de processus fils par clonage, il ne sert aucune requête et ne traite aucun paquet réseau. Ce sont les processus fils qui traitent les connexions, servent des connexions multiples (une à la fois) avant de mourir. Le père génère de nouveaux fils, ou tue des anciens fils inactifs pour répondre à la variation de charge du serveur. Il s’acquitte de cette tache par l'intermédiaire d'un fichier de marquage (scoreboard) que les fils renseignent également.

    Ce modèle est très robuste. En effet, même si un processus fils se « plante » cela n’affecte pas le père qui remplace rapidement le processus défaillant. De plus Apache bénéficie d'une trés grande richesse de fonctionnalitées à travers ses modules d'extension.

    Le revers de la médaille est que ce modèle de fonctionnement induit une grande consommation de ressource du fait de la génération de nombreux processus (temps de création des processus et occupation mémoire des nombreux processus) et de la commutation d’environnement entre les processus. Par exemple, si APACHE est utilisé avec PHP, tous les processus apache "embarqueront" PHP même si ils ne sont utilisés que pour servir une image gif de 2 ko ! Et comme Apache ne restitu pas la mémoire non utilisée, avec le temps, la taille des processus apache augmente et des ressources sont utilisées inutilement.

    Apache à pris ce problème en compte (la version 1.3 pour Windows utilise déjà un modèle multithreading) en développant parallèlement à la version 1 une version 2 d’Apache qui inclut des modèles de fonctionnement multi-tâches (multithreading) tout en offrant également le modèle pre-forking.

    Le multi-threading, en gros c'est la capacité pour un même processus d'executer plusieurs tâches en paralelle ce qui économise le temps de création d'un nouveau processus et de commutation d'environement d'un processus à l'autre.

    Malheureusement, PHP ne supporte pas le multi-threading en natif. On peut le fabriquer par codage avec les sockets sous PHP4 ou bien avec les streams de PHP5 mais on ne peux pas tirer avantage des fonctionnalité multi-threading d'apache 2. (C'est une des raisons pour laquelle de nombreux webmasters dont je suis sont resté à apache 1.3 :wink: )

    J'en profite pour préciser que Apache 2 n'est pas la nouvelle version d'Apache mais un produit différent d'Apache 1 et que les deux branches sont maintenues et développées séparément.

    Mais il existe également des alternatives à Apache sous Linux. Je ne passerais pas en revue l’ensemble des alternatives.Je me suis arrêté à lighty (lighttp) C'est l'un des serveurs WEB ayant la plus faible trace mémoire et le plus faible usage du processeur, tout en étant très rapide pour servir des documents statiques comme dynamiques.

    Lighty sert les requetes WEB à l'aide d'un processus unique de quelques Mo. En terme de resssources, sa limitation étant le nombre de fichiers ouverts simultanément par le systeme (en général c'est sous Linux mais cela peut être modifié facilement)

    Un autre avantage de lighty est qu’il ne sert pas les fichiers statiques et dynamiques à l’aide des même processus lorsqu’il est utilisé avec un module de script coté serveur . Le processus principal de lighty sert les fichiers statiques et le service des fichiers dynamiques est confié à FastCGI, lighty se comportant alors comme un serveur de proxy. Lighty est une solution fiable utilisée par de trés gros sites. Ce n’est pas un fait du hasard si des sites comme YouTube ou SourceForge ont choisi lighty !

    Si je continu à utiliser personnellement Apache 1.3 pour servir les pages HTML et PHP (ah! fidélité quand tu nous tiens ! :wink: ), j'ai mis en place de nombreuses architecture ou j'utilise lighty pour des serveur d'images et de vidéos, avec succés.

    En espérant que ce Post trés théorique éclairera de nombreux Wrinautes sur le fonctionnement de leur serveurs Apache.
     
  2. Ron56
    Ron56 WRInaute occasionnel
    Inscrit:
    20 Novembre 2005
    Messages:
    461
    J'aime reçus:
    0
    Op une reco, super article , on apprend des choses :wink:
     
  3. bozoleclown
    bozoleclown WRInaute impliqué
    Inscrit:
    24 Novembre 2005
    Messages:
    697
    J'aime reçus:
    0
    je ne comprends pas ton parallèle entre apache et php ?
    le langage php ne peut etre multithreadé, soit mais quel lien avec apache 2 ?
     
  4. fandecine
    fandecine WRInaute passionné
    Inscrit:
    2 Avril 2005
    Messages:
    1 886
    J'aime reçus:
    0
    Apache 2 est multithread, et lorsqu'il est utilisé avec PHP, PHP est inclus aux processus Apache mais du fait des limitations de PHP, ces processus ne peuvent pas êtres multithreadés, on retombe dans un modele préforking pur, comme avec apache 1.
     
  5. bozoleclown
    bozoleclown WRInaute impliqué
    Inscrit:
    24 Novembre 2005
    Messages:
    697
    J'aime reçus:
    0
    aaaaah parce que chaque thread n'embarque pas son php avec lui mais utilise le php du process fils ?

    effectivement si c'est cela je comprends mieux

    Tu connais d'autres modules d'apache qui exploite ce principe de multithread?
    Et en utilisant php en cgi et pas en module d'apache on s'en sort pas ?
     
  6. fandecine
    fandecine WRInaute passionné
    Inscrit:
    2 Avril 2005
    Messages:
    1 886
    J'aime reçus:
    0
    je pense que lorsque PHP est executé en FastCGI, le multithreading fonctionne, mais je n'en suis pas sur. C'est à vérifier.

    J'ai des serveurs qui fonctionnent avec PHP en FastCGI, et cela semble fonctionner comme un serveur autonome avec un nombre de processus fixe, un peu comme Mysql.

    Faut que je regarde tout ça de plus prés :wink:
     
  7. broidsy
    broidsy Nouveau WRInaute
    Inscrit:
    13 Octobre 2005
    Messages:
    11
    J'aime reçus:
    0
    Bravo pour cet article !

    Apparemment (je ne suis pas du tout un expert dans ce domaine) la principale limite de Lighty est de ne pas supporter les fichiers .htaccess . Bien qu'il soit quand même possible de faire de l'url rewriting, les directives ne sont évaluées qu'une seule fois, au démarrage du serveur, et nécessitent de le redémarrer afin d'être prises en compte...

    En ce qui concerne le multi-threading le problème vient effectivement de PHP. Je pense que le fonctionnement hybride de Apache 2 à été fait pour maximiser les performances sans sacrifier la stabilité : si un processus plante, le serveur reste opérationnel dans la très grande majorité des cas, ce qui n'est pas forcément vrai en multi-threading pur...

    Pour approfondir (en anglais) :
    http://www.zend.com/whitepapers/PHPandApache2-ZendWhitepaper.pdf
    http://www.zelja.com/AdminHeaven/software/Apache1.3to2.0MigrationWhitePaper.pdf

    En ce qui concerne le multi-threading sous Linux, dixit le premier PDF :
     
  8. link182
    link182 WRInaute occasionnel
    Inscrit:
    26 Juillet 2005
    Messages:
    426
    J'aime reçus:
    0
    Merci Fandeceine pour ses explications.

    Par contre aurais tu un lien sur tu tuto permettant de faire cohabiter lighttpd et apache sur le meme serveur ?
     
  9. wullon
    wullon WRInaute accro
    Inscrit:
    18 Septembre 2004
    Messages:
    2 811
    J'aime reçus:
    0
    Eu tu ne vas pas pouvoir mettre les deux sur le même port et la même IP ^^.

    edit : ok j'avais mal compris la question au départ en fait.
     
  10. link182
    link182 WRInaute occasionnel
    Inscrit:
    26 Juillet 2005
    Messages:
    426
    J'aime reçus:
    0
    lighty sur le 80 et apache sur le 8080 non ?
     
  11. fandecine
    fandecine WRInaute passionné
    Inscrit:
    2 Avril 2005
    Messages:
    1 886
    J'aime reçus:
    0
    Tout a fait !

    Apache ecoute sur le port 80 et lighty sur le 8080 (par exemple). Ensuite, il faut charger le module mod_proxy d'apache et le configurer pour renvoyer tout ce qui n'est pas PHP sur le port 8080 (lighty).

    Mais cette solution n'est pas top car apache consomme quand même un processus pour faire la redirection sur lighty. Il vaut bien mieux installer soit Apache, soit lighty et faire fonctionner le langage de script (PHP, PERL, RUBY etc) en FastCGI.

    Le top, c'est une machine avec apache+PHP qui ne traite que le PHP, et une autre machine avec lighty qui ne traite que le statique (css, js, jpg, gif, html etc ).

    Cette config permet de compiler Apache avec PHP (de façon sélective en suprimant ce qui ne sert pas) et d'arriver à une taille de processus raisonable (4 ou 5 Mo), et de tuner apache de façon trés performante puisqu'il ne sert plus qu'un type de fichiers.

    PS: Il y a d'autres solutions trés performantes, dont une que je teste, c'est Apache+PERL+MASON sur une machine et lighty sur l'autre. MASON est un framework PERL qui m'a laissé sur le cul question puissance, compacité du code et performances (Amazon.com et del-icio.us utilisent MASON) et PERL question puissance c'est le TOP !
     
  12. sietjp
    sietjp WRInaute occasionnel
    Inscrit:
    14 Décembre 2003
    Messages:
    487
    J'aime reçus:
    1
    fandecine, cnonais tu thttpd (tiny httpd) ? C'est ce que j'utilise pour mes images et ficheirs statique. Ca ressemble un peu à lighty visiblement.
     
Chargement...
Similar Threads - [article] APACHE ça Forum Date
Google victime d'abus d'incompréhension dominante [Article] Droit du web (juridique, fiscalité...) 17 Septembre 2010
monitoring apache2 ? Développement d'un site Web ou d'une appli mobile 28 Octobre 2019
Incohérences stats de crawl et logs apache Crawl et indexation Google, sitemaps 25 Juillet 2019
Renewal letsencrypt plante Apache Administration d'un site Web 12 Avril 2019
Coupure intempestive apache Développement d'un site Web ou d'une appli mobile 14 Mars 2019
Apache et QUIC (http/3) Administration d'un site Web 14 Novembre 2018
Tracer le fonctionnement d'Apache (2.2.15) Administration d'un site Web 23 Avril 2018
Tuto http->https pour apache Administration d'un site Web 9 Mars 2018
Redirection de page avec virtualhost d'apache Développement d'un site Web ou d'une appli mobile 6 Février 2017
Charset apache / php ? Administration d'un site Web 6 Juin 2016