[article] APACHE, comment ça marche ?

[fandecine]

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 )

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 ! ), 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.

[Ron56]

Op une reco, super article , on apprend des choses

[bozoleclown]

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...

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 ?

[fandecine]

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 ?

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.

[bozoleclown]

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.

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 ?

[fandecine]

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

[broidsy]

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 :

For example, if you are using Linux, the gain from using threads is typically quite negligible. The reason for that is that threads under Linux are implemented as processes with shared resources, so unlike other operating systems – threads are not more lightweight than processes. In other operating systems such as Solaris, the performance gain from using threads may be more visible.

[link182]

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 ?

[wullon]

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.

[link182]

lighty sur le 80 et apache sur le 8080 non ?

[fandecine]

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 !

[sietjp]

fandecine, cnonais tu thttpd (tiny httpd) ? C'est ce que j'utilise pour mes images et ficheirs statique. Ca ressemble un peu à lighty visiblement.