WRInaute passionné
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.
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.
