La question « Comment faire en sorte que les pages de mon site soient servies rapidement ? » reviens souvent. Si vous utilisez un hébergement mutualisé, c’est uniquement du coté CMS voire langage (PHP le plus souvent) qu’il va falloir travailler. Si vous possédez votre propre serveur dédié, vous pourrez agir directement à la source : optimiser le serveur web lui même.
Ce tutoriel a pour but de donner des pistes vous permettant d’optimiser au mieux, en comprenant à peu près ce que vous faites, un serveur rencontré classiquement : Apache dans sa version 2, tournant bien évidemment sur un système GNU/Linux, dans le but de servir des pages générées à l’aide de PHP.
Attention : même si ces optimisations peuvent vous faire gagner pas mal de points sur PageSpeed ou YSlow, ce tutoriel a pour unique sujet l’optimisation d’Apache. De même, il ne sera pas question ici de discuter de l’utilisation d’un autre serveur pour servir les contenus statiques voire de comparer les performances d’Apache avec d’autres serveurs web comme Lighttpd ou NGInx
Si votre serveur est déjà en production, il peut être intéressent d’effectuer un test de performances, par exemple à l’aide d’un outil en ligne, comme GTMetrix (créez un compte, vous pourrez ainsi accéder à plus d’options, et avoir un joli graphe de l’évolution des performances, c’est évidement gratuit) dès maintenant, et après chaque optimisation.
Prefork ou Worker ?
Il convient de choisir quelle « mouture » d’Apache utiliser. Ces moutures se choisissent en installant l’un des modules « core » déterminant le comportement d’Apache vis à vis des requêtes multiples et concurrentes. Sous GNU/Linux, Apache dispose de deux modules stables pour la production : MPM Prefork et MPM Worker. Les modules MPM dupliquent Apache afin de lui permettre de répondre à plusieurs requêtes simultanément.
La différence entre les deux est que là où MPM Prefork utilise uniquement des processus multiples pour prendre en charge les requêtes concurrentes, MPM Worker utilise des threads pour paralléliser les requêtes au sein même des processus multiples, offrant donc de meilleures performances mais imposant d’utiliser uniquement des module Apache supportant eux même les threads, interdisant donc l’utilisation du module mod_php, permettant à Apache d’interprêter les scripts PHP.
La configuration que nous utiliserons sera donc Apache 2 MPM Prefork avec PHP installé en tant que module (mod_php)
Certains objecterons qu’on aurait très bien pu utiliser MPM Worker et exécuter les scripts PHP via une interface CGI (mod_cgi, mod_fastcgi voire mod_speedycgi) et ils auront raion… cependant, même avec des optimisations, cette solution sera toujours moins performante que MPM Prefok avec mod_php, et l’utilisation d’accélérateurs de scripts PHP comme la mise en cache d’op-code est impossible en dehors de mod_php : lorsqu’on utilise PHP avec Apache pour un site nécessitant de la performance, mod_php est un choix plus que judicieux.
Points à améliorer
« Qu’est-ce qui pourrait bien ralentir un serveur Apache ? » Est la question à laquelle nous allons répondre afin de déterminer les points à améliorer pour permettre à Apache de servir les pages plus vite.
Accès disque
Un accès disque est toujours coûteux en temps, malgré les optimisations effectuées par le système d’exploitation. À chaque requête d’une page web, outre les accès disques effectués pour récupérer les données des fichiers à servir, d’autres accès disque sont effectués, comme par exemple l’inscription des évènements dans les fichiers log, le calcul de l’ETag mais aussi la lecture d’un fichier .htaccess ou la recherche d’un fichier d’index !
Requêtes DNS
Des requêtes DNS peuvent être effectuées par Apache lorsque, par exemple, il est configuré pour afficher les noms d’hôtes correspondant à l’adresse IP des visiteurs dans les fichiers logs. Certains modules, comme mod_defensible ou mod_rbl peuvent effectuer plusieurs requêtes DNS afin de vérifier si l’adresse IP et/ou le nom d’hôte de la connexion à Internet du visiteur fait partie ou non d’une ou plusieurs listes noires.
Taille des fichiers
Chaque octet compte : chaque octet servi par votre serveur aura un impact direct sur le temps qu’il mettra a finir de servir la ressource demandée, et la compression est non seulement très efficace sur les fichiers texte, mais elle est aussi supportée par de plus en plus de navigateurs tels que Firefox ou Safari ; ça tombe bien, Apache sais compresser à la volée les contenus à servir lorsque le navigateur le supporte.
Nombre de requêtes
Chaque connexion est coûteuse en temps et en ressources : il serait formidable de pouvoir signifier au navigateur des visiteurs que certains fichiers ne sont modifier peu souvent et qu’il peut les mettre en cache et les afficher directement au lieu d’effectuer une requête pour chacun d’eux… heureusement, Apache possède un module qui permet de gérer la manière de signifier aux navigateurs les modalités de mise en cache des fichiers selon leur type.
Configuration d’Apache
Apache a besoin d’indications pour savoir comment réagir lors des pics de charge et être suffisamment réactif. La configuration idéale pour votre serveur sera déterminée en fonction de la RAM disponible, de celle consumée par la génération des pages, du type de documents servis, mais aussi de la fréquence et du nombre des visites et du trafic. Cette configuration doit être mûrement réfléchie, certaines valeurs, choisies avec discernement peuvent sauver Apache de crash fâcheux lors de pics de visite, ou tout simplement lui permettre d’utiliser au mieux les ressources nécessaires à son fonctionnement.
Que faire ?
Maintenant que nous avons vu les éléments clés, établissons un plan d’action, le détail des actions sera vu dans la deuxième partie. Bien évidemment, tout cela est à ajuster au cas par cas, selon les besoins réels de votre serveur.
Accès disque
Afin de limiter les accès disque au strict nécessaire (la récupération des données à envoyer au client), nous allons :
- Désactiver l’utilisation des ETags
Ce système, en plus d’être obsolète est inutile lorsqu’on active le module de gestion du cache d’Apache. - Ne pas autoriser l’usage des fichiers .htaccess et rapatrier le contenu de ces fichiers dans les fichiers de définition des vhosts
- Réduire, vhost par vhost, le nombre de possibilités concernant le fichier d’index
- Désactiver l’option Multiview afin de gagner du temps
- Réduire le niveau d’inscription des évènements dans les fichiers logs à ce qui est réellement utile, vhost par vhost
Requêtes DNS
Afin de supprimer les requêtes DNS, nous allons :
- Faire en sorte de n’afficher que les adresses IP dans les fichiers log
- Désactiver les modules de vérification de RBL
Taille des fichiers
Afin de réduire la taille des fichiers, nous allons activer la compression dynamique en fonction du navigateur.
Nombre de requêtes
Pour diminuer le nombre de requêtes, nous allons activer et configurer le module de mise en cache pour le serveur entier et chaque vhost si besoin, en fonction du contenu, des fichiers à servir et de la fréquence de rafraichissement des données.
Configuration d’Apache
Nous allons configurer Apache à partir de données que nous allons récolter :
- La mémoire allouée à Apache
Si le serveur héberge un serveur de bases de données comme MySQL ou d’autres services : il conviendra de déterminer quelle quantité de RAM leur réserver et de laisser le reste à Apache. - La mémoire consommée par un processus d’Apache
Pour déterminer la taille de cette mémoire, il faudra exécuter une série de requête (à l’aide d’un ab -n 1000 -c 10 http://votre.url par exemple) tout en exécutant un top ou htop en même temps sur le serveur. - La durée de chargement maximal de vos pages
À l’aide du plugin PageSpeed pour le plugin FireBug pour Firefox par exemple.
Il peut paraître curieux de se baser sur une mesure de vitesse de chargement de page, ou de mesurer la RAM utilisée par des processus afin de permettre d’accélérer Apache, mais c’est la seule manière de déterminer, par itérations successives et tâtonnements, les bonnes valeurs pour votre Apache. Il conviendra d’effectuer ces réglages après avoir effectué les autres optimisations, mais aussi après chaque modification majeure de vos scripts PHP car chaque modification modifie aussi la quantité de RAM dont ils ont besoin, donc celle nécessaire à Apache, donc ses paramètres.
La question «Comment faire en sorte que les pages de mon site soient servies rapidement ?» reviens souvent. Si vous utilisez un hébergement mutualisé, c’est uniquement du coté CMS voire langage (PHP le plus souvent) qu’il va falloir travailler. Si vous possédez votre propre serveur dédié, vous pourrez agir directement à la source : optimiser le serveur web lui même.
Ce tutoriel a pour but de donner des pistes vous permettant d’optimiser au mieux, en comprenant à peu près ce que vous faites, un serveur rencontré classiquement, Apache dans sa version 2, tournant bien évidemment sur un système GNU/Linux, dans le but de servir des pages générées à l’aide de PHP.
Attention : même si effectuer ces optimisations peuvent vous faire gagner pas mal de points sur Page Speed ou
Si votre serveur est déjà en production, il peut être très intéressent d’effectuer un test de performances, par exemple à l’aide d’un outil en ligne, comme http://gtmetrix.com/ (créez un compte, vous pourrez ainsi accéder à plus d’options, c’est évidement gratuit) dès maintenant, et après chaque optimisation.
Avant toute chose
Il convient de choisir quelle « mouture » d’Apache choisir. Ces moutures se choisissent en installant l’un des modules « core » déterminant le comportement d’Apache vis à vis des requêtes multiples et concurrentes. Sous GNU/Linux, Apache dispose de deux modules stables pour la production : MPM Prefork et MPM Worker. [ note : les modules MPM dupliquent Apache afin de lui permettre de répondre à plusieurs requêtes simultanément.]
La différence entre les deux est que là où MPM Prefork utilise uniquement des processus (http://fr.wikipedia.org/wiki/Processus_%28informatique%29) multiples pour prendre en charge les requêtes concurrentes, MPM Worker utilise des threads (http://fr.wikipedia.org/wiki/Thread_%28informatique%29) pour paralléliser les requêtes au sein même des processus multiples, offrant donc de meilleures performances mais imposant d’utiliser uniquement des modules supportant les threads, interdisant par la même occasion l’utilisation du module mod_php permettant à Apache d’interprêter les script PHP.
On prendra donc soin d’installer apache mpm_prefork ainsi que mod_php.
[encar Certains objecterons qu'on aurait très bien pu utiliser MPM Worker et exécuter les scripts PHP via une interface CGI (mod_cgi, mod_fastcgi voire mod_speedycgi) et ils auront raion… cpendant, même avec des optimisations, cette solution sera toujours moins performante que MPM Prefok avec mod_php. De plus, l'utilisation d'accélérateurs de scripts PHP comme la mise en cache d'op-code est impossible en dehors de mod_php. ]
Points à améliorer
Qu’est-ce qui pourrait bien ralentir notre serveur ? C’est la question qu’il est temps de se poser pour pouvoir avancer dans la bonne direction : elle nous permettra d’identifier les goulots d’étranglement qui ralentissent Apache. Nous ne parlerons pas ici d’optimisations coté PHP.
Accès disque
À chaque fois que votre serveur est sollicité, toutes les ressources dont il a besoin sont prises sur le disque. Du fichier .htaccess aux images et scripts, en passant par les logs. Un accès disque est aussi effectué à chaque fois qu’Apache doit déterminer si le fichier a été modifié ou non afin de calculer un ETAG par exemple.
Requêtes DNS
Lorsque les domaines sont affichés en clair dans les logs, lorsqu’un module vérifie si l’adresse ip d’un client figure dans une RBL ou lorsque dans une règle de contrôle d’accès à un dossier, un domaine est à vérifier, des requêtes DNS sont effectuées, ralentissant d’autant chaque traitement de requête.
Taille des fichiers transférés
Au plus la taille des fichiers transférés est faible, au plus vite la page sera affichée sur le navigateur du visiteur de votre site : il faut donc, le plus possible, réduire la taille des fichiers transférés, notamment par l’utilisation de la compression lorsque cela est possible.
Taille des requêtes
Si votre site web installe des cookies sur le navigateur client, ces derniers seront joints à chaque requête, même celles concernant des fichiers statiques invariants.
Nombre de requêtes pour une page
Dans votre page web, chaque script, chaque image, ou feuille de style est une requête supplémentaire à laquelle votre serveur devra répondre. Peut être qu’il n’est pas utile de tout recharger à chaque fois, et que le navigateur de l’internaute peut éventuellement mettre tout ou partie d’un contenu statique en cache
Mauvaise configuration
Matérielle
Un serveur web, on l’a vu plus haut, a besoin d’accéder très régulièrement au système de fichiers : utiliser un système de stockage adéquat et permettant des taux de transfert élevés est préférable.
Un serveur web a aussi besoin de RAM, suffisamment pour lui permettre de servir autant de requêtes simultanées que nécessaire, sans avoir besoin d’utiliser la partition d’échange.
On le verra plus tard, mais la RAM pourra aussi servir à mettre des ressources en cache voire d’abriter un système de fichiers volatile, selon les besoins du site (son trafic) et votre budget, au plus il y a de RAM, au mieux c’est.
Dans le cas de l’utilisation de PHP, on aura bien évidemment besoin de plus de RAM que pour servir des fichiers statiques.
Du système
Il est important de configurer le système d’exploitation de façon optimale ainsi que d’installer un certain nombre d’utilitaires permettant d’aider Apache à rester performant, comme, par exemple, un système de rotation des fichiers logs, un système de gestion d’un cache en RAM. On prendra aussi soin de faire en sorte que d’autres processus n’occupent pas le serveur inutilement (CPU et RAM).
D’Apache
Apache en lui même aura évidemment besoin d’être configuré avec discernement, mais le choix des modules ainsi que leur configuration propre est tout aussi important : certains modules, installés ou activés par défaut, ou dans leur configuration initiale peuvent faire grandement chuter les performances d’Apache.