Serveur Web · 12 min read · Jan 26, 2026
Configurer Apache pour des performances maximales
Apache est une implémentation de serveur HTTP open-source. C’est le serveur web le plus populaire sur Internet. L’enquête sur les serveurs web de décembre 2005 menée par Netcraft [
1 ] montre qu’environ 70 % des sites web sur Internet utilisent Apache.
1. Performance du serveur Apache
La performance du serveur Apache peut être améliorée en ajoutant des ressources matérielles supplémentaires telles que la RAM, un CPU plus rapide, etc. Mais, la plupart du temps, le même résultat peut être obtenu par une configuration personnalisée du serveur. Cet article examine comment obtenir des performances maximales d’Apache avec les ressources matérielles existantes, spécifiquement sur les systèmes Linux. Bien sûr, il est supposé qu’il y a suffisamment de ressources matérielles, en particulier suffisamment de RAM pour que le serveur ne swap pas fréquemment. Les deux premières sections examinent diverses options de configuration à la compilation et à l’exécution. La section d’exécution suppose qu’Apache est compilé avec le MPM
prefork . La compression HTTP et le caching sont discutés ensuite. Enfin, l’utilisation de serveurs séparés pour servir des contenus statiques et dynamiques est abordée. Une connaissance de base de la compilation et de la configuration d’Apache, ainsi que de Linux, est supposée.
2 Options de configuration à la compilation
2.1 Charger uniquement les modules requis :
Le serveur HTTP Apache est un programme modulaire où l’administrateur peut choisir la fonctionnalité à inclure dans le serveur en sélectionnant un ensemble de modules [
2 ]. Les modules peuvent être soit compilés statiquement dans le binaire httpd, soit compilés en tant qu’objets partagés dynamiques (DSO). Les modules DSO peuvent être compilés lorsque le serveur est construit ou peuvent utiliser l’utilitaire
apxs pour être compilés et ajoutés ultérieurement. Le module mod_so doit être compilé statiquement dans le cœur d’Apache pour activer le support DSO.
Exécutez apache avec uniquement les modules requis. Cela réduit l’empreinte mémoire et donc la performance du serveur. La compilation statique des modules économisera la RAM utilisée pour prendre en charge les modules chargés dynamiquement, mais il faut recompiler Apache chaque fois qu’un module doit être ajouté ou supprimé. C’est là que le mécanisme DSO est utile. Une fois que le module mod_so est compilé statiquement, tout autre module peut être ajouté ou supprimé en utilisant la commande LoadModule dans le fichier httpd.conf - bien sûr, vous devrez compiler les modules en utilisant apxs s’ils n’ont pas été compilés lors de la construction du serveur.
2.2 Choisir le MPM approprié :
Le serveur Apache est livré avec une sélection de modules de traitement multi-processus (MPM) qui sont responsables de la liaison aux ports réseau sur la machine, d’acceptation des demandes et de dispatching des enfants pour gérer les demandes [
3 ]. Un seul MPM peut être chargé dans le serveur à tout moment.
Le choix d’un MPM dépend de divers facteurs tels que le support des threads par le système d’exploitation, la quantité de mémoire disponible, la scalabilité par rapport à la stabilité, l’utilisation de modules tiers non sûrs pour les threads, etc. Les systèmes Linux peuvent choisir d’utiliser un MPM threadé comme worker ou un MPM non threadé comme prefork :
Le MPM Worker utilise plusieurs processus enfants. Il est multi-threadé au sein de chaque enfant et chaque thread gère une seule connexion. Worker est rapide et hautement scalable et l’empreinte mémoire est relativement faible. Il est bien adapté aux processeurs multiples. D’autre part, worker est moins tolérant aux modules défectueux et les threads défectueux peuvent affecter tous les threads dans un processus enfant.
Le MPM Prefork utilise plusieurs processus enfants, chaque enfant gère une connexion à la fois. Prefork est bien adapté aux systèmes à CPU unique ou double, la vitesse est comparable à celle de worker et il est hautement tolérant aux modules défectueux et aux enfants qui plantent. Mais l’utilisation de la mémoire est élevée, plus de trafic entraîne une utilisation accrue de la mémoire.
3 Options de configuration à l’exécution
3.1 Recherche DNS :
La directive HostnameLookups active la recherche DNS afin que les noms d’hôtes puissent être enregistrés au lieu de l’adresse IP. Cela ajoute de la latence à chaque demande puisque la recherche DNS doit être complétée avant que la demande ne soit terminée. HostnameLookups est désactivé par défaut dans Apache 1.3 et supérieur. Laissez-le désactivé et utilisez un programme de post-traitement tel que logresolve pour résoudre les adresses IP dans les fichiers journaux d’accès d’Apache. Logresolve est fourni avec Apache.
Lors de l’utilisation des directives Allow from ou Deny from, utilisez l’adresse IP au lieu d’un nom de domaine ou d’un nom d’hôte. Sinon, une double recherche DNS est effectuée pour s’assurer que le nom de domaine ou le nom d’hôte n’est pas usurpé.
3.2 AllowOverride :
Si AllowOverride n’est pas défini sur ‘None’, alors Apache tentera d’ouvrir le fichier .htaccess (comme spécifié par la directive AccessFileName) dans chaque répertoire qu’il visite. Par exemple :
DocumentRoot /var/www/html
Si une demande est faite pour l’URI /index.html, alors Apache tentera d’ouvrir /.htaccess, /var/.htaccess, /var/www/.htaccess, et /var/www/html/.htaccess. Ces recherches supplémentaires dans le système de fichiers ajoutent à la latence. Si .htaccess est requis pour un répertoire particulier, alors activez-le uniquement pour ce répertoire.
3.3 FollowSymLinks et SymLinksIfOwnerMatch :
Si l’option FollowSymLinks est définie, alors le serveur suivra les liens symboliques dans ce répertoire. Si SymLinksIfOwnerMatch est défini, alors le serveur suivra les liens symboliques uniquement si le fichier ou le répertoire cible appartient au même utilisateur que le lien.
Si SymLinksIfOwnerMatch est défini, alors Apache devra émettre des appels système supplémentaires pour vérifier si la propriété du lien et du fichier cible correspondent. Des appels système supplémentaires sont également nécessaires lorsque FollowSymLinks n’est PAS défini. Par exemple :
DocumentRoot /vaw/www/html
Pour une demande faite pour l’URI /index.html, Apache effectuera lstat() sur /var, /var/www, /var/www/html, et /var/www/html/index.html. Ces appels système supplémentaires ajouteront à la latence. Les résultats de lstat ne sont pas mis en cache, donc ils se produiront à chaque demande.
Pour des performances maximales, définissez FollowSymLinks partout et ne définissez jamais SymLinksIfOwnerMatch. Sinon, si SymLinksIfOwnerMatch est requis pour un répertoire, alors définissez-le uniquement pour ce répertoire.
3.4 Négociation de contenu :
Évitez la négociation de contenu pour une réponse rapide. Si la négociation de contenu est requise pour le site, utilisez des fichiers type-map plutôt que la directive Options MultiViews. Avec MultiViews, Apache doit scanner le répertoire à la recherche de fichiers, ce qui ajoute à la latence.
3.5 MaxClients :
Le MaxClients définit la limite sur le nombre maximum de demandes simultanées pouvant être prises en charge par le serveur. Pas plus que ce nombre de processus enfants ne sont créés. Il ne doit pas être défini trop bas de sorte que de nouvelles connexions soient mises en file d’attente, ce qui finit par expirer et les ressources du serveur restent inutilisées. Le fait de le définir trop haut fera que le serveur commencera à swapper et le temps de réponse se dégradera considérablement. La valeur appropriée pour MaxClients peut être calculée comme suit : MaxClients = RAM totale dédiée au serveur web / Taille maximale du processus enfant —- [
4 ] La taille du processus enfant pour servir un fichier statique est d’environ 2-3M. Pour un contenu dynamique tel que PHP, cela peut être d’environ 15M. La colonne RSS dans
"ps -ylC httpd --sort:rss"montre l’utilisation de la mémoire physique non échangée par les processus Apache en kilo-octets.
S’il y a plus d’utilisateurs concurrents que MaxClients, les demandes seront mises en file d’attente jusqu’à un nombre basé sur la directive ListenBacklog. Augmentez ServerLimit pour définir MaxClients au-dessus de 256.
3.6 MinSpareServers, MaxSpareServers et StartServers :
MaxSpareServers et MinSpareServers déterminent combien de processus enfants doivent être conservés en attendant des demandes. Si MinSpareServers est trop bas et qu’un certain nombre de demandes arrivent, alors Apache devra créer des processus enfants supplémentaires pour servir les demandes. La création de processus enfants est relativement coûteuse. Si le serveur est occupé à créer des processus enfants, il ne pourra pas servir immédiatement les demandes des clients. MaxSpareServers ne doit pas être défini trop haut, cela peut causer des problèmes de ressources puisque les processus enfants consomment des ressources.
Ajustez MinSpareServers et MaxSpareServers de sorte qu’Apache n’ait pas à créer fréquemment plus de 4 processus enfants par seconde (Apache peut créer un maximum de 32 processus enfants par seconde). Lorsque plus de 4 enfants sont créés par seconde, un message sera enregistré dans l’ErrorLog.
La directive StartServers définit le nombre de processus de serveur enfants créés au démarrage. Apache continuera à créer des enfants jusqu’à ce que le paramètre MinSpareServers soit atteint. Cela n’a pas beaucoup d’effet sur les performances si le serveur n’est pas redémarré fréquemment. S’il y a beaucoup de demandes et qu’Apache est redémarré fréquemment, définissez cela à une valeur relativement élevée.
3.7 MaxRequestsPerChild :
La directive MaxRequestsPerChild définit la limite sur le nombre de demandes qu’un processus serveur enfant individuel traitera. Après MaxRequestsPerChild demandes, le processus enfant mourra. Il est défini sur 0 par défaut, ce qui signifie que le processus enfant ne mourra jamais. Il est approprié de le définir à une valeur de quelques milliers. Cela peut aider à prévenir les fuites de mémoire puisque le processus meurt après avoir servi un certain nombre de demandes. Ne le définissez pas trop bas, car la création de nouveaux processus a un coût.
3.8 KeepAlive et KeepAliveTimeout :
La directive KeepAlive permet d’envoyer plusieurs demandes sur la même connexion TCP. Cela est particulièrement utile lors du service de pages HTML avec beaucoup d’images. Si KeepAlive est défini sur Off, alors pour chaque image, une connexion TCP séparée doit être établie. Le coût dû à l’établissement de la connexion TCP peut être éliminé en activant KeepAlive.
KeepAliveTimeout détermine combien de temps attendre la prochaine demande. Définissez cela à une valeur basse, peut-être entre deux et cinq secondes. S’il est défini trop haut, les processus enfants sont bloqués en attendant le client alors qu’ils pourraient être utilisés pour servir de nouveaux clients.
4 Compression HTTP & Caching
La compression HTTP est complètement spécifiée dans HTTP/1.1. Le serveur utilise la méthode d’encodage gzip ou deflate pour le payload de réponse avant qu’il ne soit envoyé au client. Le client décompresse ensuite le payload. Il n’est pas nécessaire d’installer un logiciel supplémentaire du côté client puisque tous les navigateurs majeurs le prennent en charge. L’utilisation de la compression permettra d’économiser de la bande passante et d’améliorer le temps de réponse, des études ont trouvé un gain de compression moyen de 75,2 % [
5 ]. La compression HTTP peut être activée dans Apache en utilisant le module
mod_deflate . Le payload est compressé uniquement si le navigateur demande la compression, sinon un contenu non compressé est servi. Un navigateur conscient de la compression informe le serveur qu’il préfère un contenu compressé via l’en-tête de requête HTTP - “Accept-Encoding: gzip,deflate”. Ensuite, le serveur répond avec un payload compressé et l’en-tête de réponse défini sur “
Content-Encoding:
gzipL’exemple suivant utilise telnet pour voir les en-têtes de requête et de réponse :
bash-3.00$ telnet www.webperformance.org 80
Essai 24.60.234.27...
Connecté à www.webperformance.org (24.60.234.27).
Le caractère d'échappement est '^]'.
HEAD / HTTP/1.1
Host: www.webperformance.org
Accept-Encoding: gzip,deflate
HTTP/1.1 200 OK
Date: Sam, 31 Déc 2005 02:29:22 GMT
Serveur: Apache/2.0
X-Powered-By: PHP/5.1.1
Cache-Control: max-age=0
Expires: Sam, 31 Déc 2005 02:29:22 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Content-Type: text/html; charset=ISO-8859-1
Dans le caching, une copie des données est stockée du côté client ou dans un serveur proxy afin qu’elle ne doive pas être récupérée fréquemment depuis le serveur. Cela permettra d’économiser de la bande passante, de diminuer la charge sur le serveur et de réduire la latence. Le contrôle du cache se fait via des en-têtes HTTP. Dans Apache, cela peut être accompli via les modules mod_expires et mod_headers. Il existe également un caching côté serveur, dans lequel les contenus fréquemment accédés sont stockés en mémoire afin qu’ils puissent être servis rapidement. Le module mod_cache peut être utilisé pour le caching côté serveur, il est stable en production dans la version 2.2 d’Apache.
5 Serveur séparé pour le contenu statique et dynamique
Les processus Apache servant du contenu dynamique prennent environ 3M à 20M de RAM. Il grandit pour s’adapter au contenu qu’il sert et ne diminue jamais jusqu’à ce que le processus meure. Disons qu’un processus Apache grandit à 20M pour servir un contenu dynamique. Après avoir terminé la demande, il est libre de servir toute autre demande. Si une demande pour une image arrive, alors ce processus de 20M sert un contenu statique qui pourrait tout aussi bien être servi par un processus de 1M. La mémoire est utilisée de manière inefficace.
Utilisez un petit Apache (avec un minimum de modules compilés statiquement) comme serveur frontal pour servir des contenus statiques. Les demandes de contenus dynamiques sont transférées au lourd Apache (compilé avec tous les modules requis). L’utilisation d’un serveur frontal léger a l’avantage que les contenus statiques sont servis rapidement sans une grande utilisation de mémoire et seuls les contenus dynamiques sont transmis au serveur lourd.
Le transfert de demandes peut être réalisé en utilisant les modules mod_proxy et rewrite_module. Supposons qu’il y ait un serveur Apache léger écoutant sur le port 80 et le lourd Apache écoutant sur le port 8088. Alors la configuration suivante dans l’Apache léger peut être utilisée pour transférer toutes les demandes sauf celles pour les images au serveur lourd.
ProxyPassReverse / http://%{HTTP_HOST}:8088/
RewriteEngine on ---- [9]
RewriteCond %{REQUEST_URI} !.*\.(gif|png|jpg)$
RewriteRule ^/(.*) http://%{HTTP_HOST}:8088/$1 [P]Toutes les demandes, sauf celles pour les images, sont proxyées au serveur backend. La réponse est reçue par le serveur frontal puis fournie au client. En ce qui concerne le client, toutes les réponses semblent provenir d’un seul serveur.
6 Conclusion
Configurer Apache pour des performances maximales est délicat, il n’y a pas de règles strictes. Comprenez les exigences du serveur web et expérimentez avec les différentes options disponibles. Utilisez des outils comme
ab et
httperf pour mesurer les performances du serveur web. Des serveurs légers tels que
tux ,
thttpd peuvent également être utilisés comme serveur frontal. Si un serveur de base de données est utilisé, assurez-vous qu’il est optimisé pour ne pas créer de goulets d’étranglement. Dans le cas de MySQL,
mtop peut être utilisé pour surveiller les requêtes lentes. La performance des scripts PHP peut être améliorée en utilisant un produit de caching PHP tel que
Turck MMCache . Cela élimine le coût dû à la compilation en mettant en cache les scripts PHP dans un état compilé.
Bibliographie
1 http://news.netcraft.com/archives/web_server_survey.html
2 http://httpd.apache.org/docs/2.2/dso.html
3 http://httpd.apache.org/docs/2.2/mpm.html
4 http://modperlbook.org/html/ch11_01.html
5 http://www.speedupyoursite.com/18/18-2t.html
6 http://www.xs4all.nl/~thomas/apachecon/PerformanceTuning.html
7 http://www.onlamp.com/pub/a/onlamp/2004/02/05/lamp_tuning.html
8 http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
9 Linux Server Hacks par Rob Flickenger
Biographie de l’écrivain : Vishnu Ram est titulaire d’un MTech. en systèmes de communication de l’IIT Madras. Il a rejoint Bobcares en 2003 et travaille pour Poornam depuis lors.
Recevez de nouveaux articles dans votre boîte de réception.
Aucun spam. Désabonnez-vous à tout moment.