[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 873
    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:
    460
    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:
    693
    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 873
    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:
    693
    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 873
    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 788
    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 873
    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:
    476
    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
[Article] Lighttpd et apache sur le même serveur II Administration d'un site Web 26 Juin 2008
[article] Bien configurer apache Administration d'un site Web 27 Novembre 2006
Google victime d'abus d'incompréhension dominante [Article] Droit du web (juridique, fiscalité...) 17 Septembre 2010
[Article] Automatisez le déploiement de vos sites Administration d'un site Web 13 Août 2009
[Article] Les journaux cherchent le moyen de faire payer leur contenu Monétisation d'un site web 24 Mars 2009
[article] Exploiter les stats Google Webmaster Tools Référencement Google 16 Octobre 2008
[article] backlinks: la mort de l' Ancre Référencement Google 30 Septembre 2008
[Article] [beta]Sauvegarder un dédié part II Administration d'un site Web 13 Juin 2008
[Article] Configurer lighttpd (lighty) avec php5 Administration d'un site Web 16 Janvier 2008
[Article] Exemple de script de sauvegarde pour un dédié Administration d'un site Web 13 Janvier 2008
[article] Faire évoluer son architecture serveur Administration d'un site Web 4 Novembre 2007
[article] illustration de la force ds liens internes Référencement Google 19 Août 2007
[article] Optimiser son serveur dedié part II Administration d'un site Web 12 Février 2007
[article] Sécuriser son serveur LAMP Administration d'un site Web 18 Août 2006
[article] Optimiser son serveur dédié Administration d'un site Web 8 Mai 2006
[Article] Link Spam Detection Based on Mass Estimation Techniques avancées de référencement 9 Novembre 2005
[article] Google, Yahoo et MSN unis contre le spam ? Techniques avancées de référencement 26 Janvier 2005
[Article] L'effet sandbox sur Google Référencement Google 29 Décembre 2004
[Article] Le poids des mots, le choc des URL :-) Référencement Google 8 Décembre 2004
[Article] La commande link:URL sur Google Netlinking, backlinks, liens et redirections 5 Décembre 2004