Voici cinq règles pour vous aider à optimiser votre installation de WordPress, ainsi que quelques exemples pour illustrer comment les appliquer. L’optimisation des serveurs est un vaste domaine, et il est en constante évolution, mais nous pouvons étudier les cas simples à comprendre.

Dans cet article, nous allons nous concentrer sur un petit nombre de variables et mesurer leur impact sur les performances.

Vous ne pouvez pas optimiser sans effectuer une analyse comparative

Il existe différents outils dont vous avez besoin pour faire une évaluation correcte, mais pour cet article nous allons nous concentrer sur le plus important : Benchmark Apache. Utilisez cet outil pour interroger des pages spécifiques sur votre site Web (vous pouvez même lui passer des informations pour simuler un cookie authentifié) et obtenir le temps réponse. Vous pouvez utiliser le Benchmark Apache en ligne de commande sur le serveur que vous testez et ainsi obtenir des résultats valables, car il a une trace entre le CPU et la RAM.

Voici une utilisation typique :

Les valeurs définies dans cette ligne de commande sont :

• n : nombre de demandes de page
• c : connexions simultanées

Le paramètre le plus important est c, le nombre de requêtes simultanées, tandis que n est un nombre qui doit être assez grand pour fournir des résultats stables. L’astuce consiste à tester le site avec diverses valeurs de c, en commençant par un petit nombre et l’augmenter jusqu’à ce que la valeur retournée de « requêtes par seconde » commence à diminuer. Voici un exemple :

On peut affiner la valeur de c en l’incrémentant petit à petit.

Réduire l’empreinte mémoire jusqu’à la fin de la page

La raison la plus probable pour laquelle les requêtes par seconde (requests per second) chutent brusquement, est parce que nous surchargeons la mémoire et le système commence à swapper en mémoire virtuelle paging file. Il s’agit d’un fichier qui, en quelque sorte joue le rôle de chasseur virtuel. Lorsque la charge imposée approche le point de saturation de la mémoire vive installée, le système tente d’en obtenir davantage et se met en quête d’un substitut en sollicitant le fichier de chasse (paging file), c’est-à-dire la mémoire virtuelle.
Cela a les mêmes effets sur la performance globale que lors de l’ouverture de trop d’applications sur Windows, Mac OS X, ou tout autre système prenant en charge le paging.

Après avoir lancé votre benchmark, jetez un œil à la façon dont le fichier d’échange (swap file) est utilisé. Voici des valeurs sur un serveur de 4Go de RAM :

Ici on utilise seulement 16 Mo du fichier d’échange (swap file). En revanche, dès que l’on augmente le nombre de connexions simultanées (c), on peut monter très rapidement la valeur du fichier d’échange. En clair, ce que vous devez faire en premier lieu, c’est ramener la valeur au plus proche de zéro :

Maintenant, le but est de refaire le test ci-dessus avec les valeurs de c qui sont proches de celui où nous voyons une baisse de performance, et vérifier le fichier d’échange, après chaque demande :

Comme vous pouvez le voir dans les résultats ci-dessus, le taux des requêtes commence à diminuer de façon significative lorsque le serveur commence à swapper avec environ 40 connexions simultanées.

Attention aux nombres de connexions…

Par défaut, Apache et MySQL sont configurés pour accepter 150 connexions. La plupart des applications PHP tels que WordPress, autorisent seulement une connexion par thread, vous pouvez donc, sans risque, définir le nombre de connexions des deux services avec la même valeur.

Note : Sachez que MySQL permet de gérer n+1 connexions, vous permettant d’avoir une connexion supplémentaire disponible en cas de gestion du serveur de base de données.

Malheureusement, dans la tentative « d’optimiser » un serveur, certains administrateurs de serveur pourront augmenter le nombre de connexions à 500, 10000, voir plus… Mais l’effet obtenu est catastrophique, dès lors que le serveur monte en charge (load average).

Des sites comme WordPress ne nécessitent généralement pas plus de 32 Mo de RAM par requête, et vous pouvez observer la valeur moyenne en regardant les résultats retournés par la commande top :

L’astuce consiste à estimer la quantité de mémoire utilisée par Apache, en faisant la moyenne des valeurs de la colonne « RES » (The non-swapped physical memory a task has used) utilisées par les processus. Dans notre exemple la valeur moyenne des « RES » est d’environ 29 Mo.

Vous devez aussi regarder la somme de la mémoire libre lorsque le serveur n’est pas sous la charge du processus httpd2.

Ici, la quantité de mémoire libre disponible est de 275852Ko, soit 269Mo.

Maintenant, pour confirmer la valeur c constatée ci-dessus, on utilise la formule suivante :

Cette valeur est le seuil où le serveur commence à s’effondrer. Il est indispensable d’éviter qu’Apache effondre le serveur. Pour cela, nous pouvons réduire le nombre de clients de 150 à 9 pour observer l’impact sur la performance.

Pour Apache, éditez le fichier de configuration (dans mon cas c’est /etc/apache2/httpd.conf) et ajustez cette valeur:

Pour MySQL, ajustez cette valeur :

Une fois que vous avez modifié ces valeurs avec le résultat obtenu ci-dessus (dans notre cas nous allons utiliser 9), relancer votre benchmark :

Comme vous pouvez le voir, le paging est éliminé. Mais pourquoi sommes-nous capables de répondre à plus de quarante demandes concurrentes ? Simplement parce qu’Apache met les requêtes supplémentaires dans une file d’attente, et ne traite seulement que quarante demandes en même temps.
De fait, la réponse au client sera toujours retardée, mais chaque demande est traitée à la seconde évitant ainsi de surcharger la mémoire.

MySQL = RAM

Évidemment, les résultats ci-dessus supposent que votre serveur de base de données soit correctement configuré et que nous n’ayons pas de slow queries. En fait, MySQL n’est généralement pas consommateur de ressources CPU pour les sites comme WordPress. Sur un serveur bien configuré, MySQL ne consomme que 10 à 25% du CPU.

En dehors de la recherche, les requêtes sont très redondantes, et on tire profit des avantages de MySQL qui sont l’optimisation du cache et des fils d’exécution (threads). Il n’est pas rare de voir MySQL configuré pour utiliser près de 50% de la RAM disponible.

Bien entendu, ces chiffres dépendent de la demande. La règle est de donner à MySQL autant de RAM que possible.

Apache = CPU

Sur les sites comme WordPress, Apache passe la majorité de son temps à exécuter du code PHP. En fait, un bon indicateur de l’optimisation des serveurs, c’est quand Apache utilise 100% du CPU disponible.

Parce que, si vous permettez à Apache de répondre à un trop grand nombre de requêtes concourantes, le taux de requêtes par seconde ne fera qu’augmenter !

Conclusion

Dans cet article je viens de décrire certains aspects de l’optimisation des serveurs. Nous avons dû faire plusieurs hypothèses pour y arriver, mais j’espère que les points étaient clairs, et qu’ils vous aideront à faire de meilleurs choix lors de vos futurs déploiements.

Avez-vous déjà été confronté à des problèmes d’optimisation ? Si c’est le cas, pouvez-vous venir en parler dans les commentaires. Il serait intéressant de comparer nos points de vue mais également les différentes solutions que l’on peut y apporter.