5 conseils pour booster les performances de votre serveur web Apache

Selon un rapport récent de Netcraft (une société Internet bien connue qui fournit entre autres des statistiques d’utilisation des navigateurs Web), Apache continue d’être le serveur Web le plus utilisé parmi les sites et les ordinateurs connectés à Internet.

De plus, Apache continue de connaître la plus forte croissance parmi les meilleurs serveurs Web, suivi de Nginx et IIS. Ainsi, si vous êtes un administrateur système en charge de la gestion des installations d’Apache, vous devez savoir comment vous assurer que votre serveur web fonctionne au mieux de ses capacités en fonction de vos besoins (ou de ceux de votre client).

Dans cet article, nous allons aborder quelques conseils qui vous aideront à vous assurer qu’Apache fonctionnera sans problème et sera capable de gérer le nombre de requêtes que vous attendez de clients distants.

Cependant, gardez à l’esprit qu’Apache n’a pas été conçu dans le but d’établir des records de référence - mais, même ainsi, il est toujours capable de fournir des performances élevées dans presque tous les cas d’utilisation auxquels vous pouvez penser.

ASTUCE #1 : Gardez toujours Apache à jour vers sa dernière version

Il va sans dire que l’installation de la dernière version d’Apache est probablement l’une des premières choses que vous devez prendre en compte. Depuis le 19 novembre 2015, la dernière version d’Apache disponible dans les dépôts CentOS 7 est la 2.4.6, alors que dans celui de Debian est la 2.4.10.

Cependant, il se peut qu’une amélioration récente ou une correction de bogue ait été ajoutée à une version stable récemment publiée, qui est ensuite disponible au téléchargement et à l’installation à partir des sources. Des instructions de compilation et d’installation sont également fournies ici - n’oubliez pas que si vous choisissez cette méthode de mise à jour, vous voudrez peut-être sauvegarder vos fichiers de configuration/sites/hôtes virtuels actuels par précaution.

Dans tous les cas, vous pouvez vérifier votre version actuellement installée comme suit :

# httpd -v               [On RedHat/CentOS based systems]
apache2 –v             [On Debian/Ubuntu based systems]

En règle générale, respectez la méthode de mise à jour fournie par le gestionnaire de paquets de la distribution de votre choix (yum update httpd ou aptitude safe-upgrade apache2, pour CentOS ou Debian, respectivement) à moins qu’il n’y ait pas d’autre moyen. Vous pouvez lire les dernières notes de mise à jour dans la section Documentation Apache du site Web du projet de serveur HTTP Apache.

ASTUCE #2 : Si vous utilisez un noyau plus ancien que 2.4, envisagez de mettre à niveau dès maintenant

Pourquoi? Les versions 2.4 et ultérieures du noyau ont l’appel système du noyau sendfile activé par défaut. Cela facilite les transferts de fichiers réseau haute performance (qui sont souhaités dans le contexte des communications serveur Web-client) et permet à Apache de fournir du contenu statique plus rapidement et avec une utilisation plus faible du processeur en effectuant des opérations de lecture et d’envoi simultanées.

Vous pouvez afficher votre noyau actuellement installé avec :

# uname -r

et comparez-le au dernier noyau stable de www.kernel.org (4.3 au moment de la rédaction de cet article).

Bien qu’il s’agisse d’un processus qui n’est pas destiné aux débutants, la mise à niveau de votre noyau est un exercice intéressant pour en savoir plus sur les rouages de Linux.

ASTUCE #3 : Choisissez le module multi-traitement (MPM) qui convient le mieux à votre cas

En pratique, les MPM étendent les fonctionnalités modulaires d’Apache en vous permettant de décider comment configurer le serveur Web pour qu’il se lie aux ports réseau de la machine, accepte les demandes des clients et utilise des processus enfants (et des threads, alternativement) pour gérer ces demandes.

À partir de la version 2.4, Apache propose trois MPM différents parmi lesquels choisir, en fonction de vos besoins :

Le MPM prefork utilise plusieurs processus fils sans threading. Chaque processus gère une connexion à la fois sans créer de threads distincts pour chacune. Sans entrer dans les détails, nous pouvons dire que vous ne voudrez utiliser ce MPM que lors du débogage d’une application qui utilise, ou si votre application doit gérer, des modules non thread-safe comme mod_php.
Le MPM de travail utilise plusieurs threads par processus enfant, où chaque thread gère une connexion à la fois. Il s’agit d’un bon choix pour les serveurs à fort trafic, car il permet de gérer davantage de connexions simultanées avec moins de RAM que dans le cas précédent.
Enfin, l’événement MPM est le MPM par défaut dans la plupart des installations Apache pour les versions 2.4 et supérieures. Il est similaire au MPM worker en ce sens qu’il crée également plusieurs threads par processus enfant, mais avec un avantage : il fait en sorte que les connexions KeepAlive ou inactives (tant qu’elles restent dans cet état) soient gérées par un seul thread, libérant ainsi de la mémoire qui peut être allouée à d’autres threads. Ce MPM n’est pas adapté à une utilisation avec des modules non thread-safe comme mod_php, pour lesquels un remplacement tel qu’un PHP-FPM doit être utilisé à la place.

Pour vérifier le MPM utilisé par votre installation Apache, vous pouvez faire :

# httpd -V

L’image ci-dessous montre que ce serveur Web particulier utilise le MPM prefork.

Pour changer cela, vous devrez modifier :

# /etc/httpd/conf.modules.d/00-mpm.conf          [On RedHat/CentOS based systems]
/etc/apache2/mods-available/<mpm>.load   [On Debian/Ubuntu based systems]

Où <mpm> peut être mpm_event, mpm_worker ou mpm_prefork.

et décommentez la ligne qui charge le module souhaité comme suit :

LoadModule mpm_event_module modules/mod_mpm_event.so

Remarque : Pour que l’événement MPM fonctionne dans Debian, vous devrez peut-être installer le paquet libapache2-mod-fastcgi à partir des dépôts non libres.

De plus, pour CentOS, vous aurez besoin de php-fpm (avec fcgi et mod_fcgid) alors que dans Debian, il s’appelle php5-fpm (avec apache2-mpm-event).

Enfin, redémarrez le serveur web et le service php-fpm (ou php5-fpm) nouvellement installé :

Sur RedHat/CentOS

# systemctl restart httpd php-fpm && systemctl enable httpd php-fpm

Sur Debian/Ubuntu

# systemctl restart apache2 php5-fpm && systemctl enable apache2 php5-fpm

Bien que vous puissiez configurer Apache pour qu’il utilise un MPM spécifique, cette configuration peut être remplacée par hôte virtuel de la même manière que celle indiquée précédemment.

Il suffit de déposer les balises correspondantes dans le fichier de configuration de chaque hôte virtuel et vous êtes prêt à partir, mais assurez-vous d’utiliser un et un seul MPM par serveur virtuel.

Enfin, veuillez noter que quelle que soit la distribution que vous avez choisie, php-fpm s’appuie sur l’implémentation de FastCGI, c’est la raison pour laquelle j’ai recommandé les installations de paquets supplémentaires plus tôt.

Pour plus de détails et d’exemples sur php-fpm et comment il peut, avec l’événement MPM, augmenter les performances d’Apache, vous devriez vous référer à la documentation officielle.

Voici ce que je vois après avoir changé le MPM par défaut de prefork à event dans la même boîte que celle illustrée dans l’image précédente :

Dans CentOS 7, vous devez vous assurer que les services http et https sont activés via le pare-feu et que la ou les interfaces réseau sont correctement ajoutées à la zone par défaut.

Par exemple:

# firewall-cmd --zone=internal --add-interface=tun6to4 
firewall-cmd --zone=internal --add-interface=tun6to4 --permanent 
firewall-cmd --set-default-zone=internal 
firewall-cmd --add-service=http 
firewall-cmd --add-service=https 
firewall-cmd --add-service=http --permanent 
firewall-cmd --add-service=https --permanent 
firewall-cmd --reload

La raison pour laquelle je soulève ce problème est que j’ai récemment rencontré un problème où les paramètres de configuration par défaut du pare-feu dans un VPS cloud empêchaient php-fpm et Apache de traiter les fichiers php.

Comme test de base (je suis sûr que vous pouvez penser à des plus compliqués ou stressants), je vais créer un fichier php qui vérifie l’existence d’un autre fichier nommé test.php dans le même répertoire de deux serveurs CentOS 7 avec les mêmes caractéristiques matérielles et la même charge mais avec des MPM différents. L’un d’eux utilisera event et l’autre utilisera prefork :

Voici le code php que j’ai enregistré dans un fichier nommé checkiffileexists.php :

<?php
$filename = 'test.php';

if (file_exists($filename)) {
    echo "The file $filename exists";
} else {
    echo "The file $filename does not exist";
}
?>

Ensuite, nous exécuterons l’outil de benchmark Apache (ab) avec 200 requêtes simultanées jusqu’à ce que 2000 requêtes soient complétées :

# ab -k -c 100 -n 2000 localhost/checkiffileexists.php

Exécutons le test et comparons les résultats. Faites attention aux statistiques de performance :

Comme vous pouvez le voir, les performances du serveur avec event sont largement supérieures à celles de son homologue pré-fork dans tous les aspects de ce test.

ASTUCE #4 : Allouez judicieusement de la RAM pour Apache

L’élément matériel le plus critique à prendre en compte est peut-être la quantité de RAM allouée à chaque processus Apache. Bien que vous ne puissiez pas contrôler cela directement, vous pouvez restreindre le nombre de processus enfants via la directive MaxRequestWorkers (anciennement connue sous le nom de MaxClients dans Apache 2.2), qui limitera l’utilisation de la RAM par Apache. Là encore, vous pouvez définir cette valeur par hôte ou par hôte virtuel.

Pour ce faire, vous devez prendre note de la quantité moyenne de RAM utilisée par Apache, puis la multiplier par le nombre de MaxRequestWorkers, et c’est la quantité de mémoire qui sera allouée aux processus Apache. Une chose que vous ne voulez jamais que votre serveur Web fasse est de commencer à utiliser swap, car cela réduira considérablement ses performances. Ainsi, vous devez toujours maintenir l’utilisation de la RAM par Apache dans les limites que vous pouvez vous permettre et ne jamais compter sur l’échange pour cela.

Par exemple, le bloc suivant limitera le nombre de clients simultanés à 30. Si d’autres clients atteignent l’hôte, ils peuvent rencontrer un retard ou une défaillance momentanée qui peut être facilement résolue en actualisant le navigateur. Bien que cela puisse être considéré comme indésirable, c’est plus sain pour le serveur et, à long terme, c’est aussi le meilleur pour votre site.

Vous pouvez placer ce bloc dans /etc/httpd/conf/httpd.conf ou /etc/apache2/apache2.conf, selon que vous utilisez CentOS ou Debian.

Veuillez noter que le même principe s’applique à tous les MPM – j’utilise event ici pour continuer avec le concept décrit dans le conseil précédent :

<IfModule mpm_event_module>
    StartServers 3
    MinSpareThreads          25
    MaxSpareThreads          75
    ThreadLimit                      64
    ThreadsPerChild          25
    MaxRequestWorkers    30
    MaxConnectionsPerChild    1000
</IfModule>

Dans tous les cas, il est fortement recommandé de vous référer à la documentation d’Apache 2.4 pour voir quelles directives sont autorisées pour le MPM que vous avez choisi.

CONSEIL #5 : Connaissez vos applications

En règle générale, vous ne devez pas charger de modules Apache qui ne sont pas strictement nécessaires au fonctionnement de votre application. Cela nécessitera au moins une connaissance globale des applications qui s’exécutent sur votre serveur, surtout si vous êtes un administrateur système et qu’il y a une autre équipe en charge du développement.

Vous pouvez lister les modules actuellement chargés avec :

# httpd -M          [On RedHat/CentOS based systems]
apache2ctl -M     [On Debian/Ubuntu based systems]

Pour décharger/désactiver des modules dans CentOS, vous devrez commenter la ligne qui commence par LoadModule (soit dans le fichier de configuration principal, soit dans un fichier auxiliaire à l’intérieur de /etc/httpd/conf.modules.d.

D’autre part, Debian fournit un outil appelé a2dismod pour désactiver les modules et est utilisé comme suit :

# a2dismod module_name

Pour le réactiver :

# a2enmod module_name

Dans les deux cas, n’oubliez pas de redémarrer Apache pour que les modifications prennent effet.

Résumé

Dans cet article, nous avons passé en revue 5 conseils qui vous aideront à régler le serveur web Apache et à augmenter ses performances. De plus, vous devez vous rappeler que l’optimisation et les performances sans sécurité sont inutiles, vous pouvez donc vous référer à l’article sur les mod_pagespeed d’installation pour améliorer les performances du serveur Web et les conseils de renforcement Apache dans linux-console.net également.

Comme nous ne pouvons pas couvrir de manière adéquate tous les aspects de ce sujet dans cet article, peut-être penserez-vous à d’autres idées que vous aimeriez partager avec le reste de la communauté. Si c’est le cas, n’hésitez pas à nous le faire savoir en utilisant le formulaire de commentaire ci-dessous.