Le socle technique actuel du blog

Cet article a été publié il y a 6 ans 2 mois 27 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

On m’a demandé récemment par mail des conseils pour améliorer la réactivité d’un blog WordPress, en comparant le mien qui serait bien plus rapide. Je n’ai pas encore de réponses définitives sur le sujet mais je pense utile de partager de manière globale les détails de l’hébergement actuel, histoire de pouvoir comparer proprement. Et quelques pistes pour savoir où trouver ce qui coince.

En effet, la description de l’infrastructure est éclatée entre un nombre beaucoup trop grand de billets éditos et autres pour en tirer quelque chose d’exploitable. On va donc reprendre couche par couche, histoire de savoir de quoi on parle.

Le matériel

Le serveur physique est un minisp32 de 2014 chez OVH localisé à Strasbourg. Il embarque un processeur Intel Xeon E3-1245v2, est accompagné de 32Go de RAM et deux disques de 2To dont la configuration peut varier via le système d’exploitation installé. Il dispose en outre d’une carte ethernet gigabit et l’abonnement d’OVH « garantit » un débit de 500Mbits par seconde. Bref, une bonne machine qui malgré les années qui commencent à s’accumuler nous a rarement fait défaut.

Le logiciel

Plus gros morceau, mais on va tout de même le faire dans l’ordre, du plus loin au plus près du blog.

L’os principal de la machine est Proxmox VE, un hyperviseur pour virtualisation qui repose sur un noyau Linux et donc les technologies lxc (containerisation d’os) et kvm (virtualisation complète). L’installation made in ovh configure les disques durs en raid 1 (miroir) ce qui sécurise un poil les données, même si ça ne remplace pas les sauvegardes.

Qui dit virtualisation dit machines virtuelles, et en l’occurrence on exploite des machines kvm. Celle qui héberge le blog, entre autres, est une machine sous Debian 8 Jessie (stretch en cours de validation). Je lui ai attribué 3vCPU et 6Go de RAM, et le disque est un assemblage avec LVM de deux volumes (petite extension suite à un besoin d’espace).

On parle d’hébergement web, et sans surprise on retrouve le tryptique de base qui est assuré par le serveur web Nginx (dépot dotdeb http2), le langage PHP 7.0 est fourni par dotdeb également (en mode FPM), et MariaDB 10 s’occupe de la base de données. En complément, j’ai ajouté un service Redis histoire de délester un peu la base de données suite aux problèmes de performances de disque certainement du à LVM (les images ne sont pas au même format, entre autres). Je pourrais également stocker les sessions dans Redis si j’étais motivé.

Et donc, le blog est propulsé par WordPress, avec un thème responsive (un seul thème pour couvrir tous les appareils), et quelques plugins pour ajouter quelques fonctionnalités plus ou moins visibles : postage sur les réseaux sociaux, affichage embarqué des images, barre de progression de lecture, vérification des liens cassés…

Comment j’ai amélioré les performances ?

On a déjà un socle qui a du muscle à plein de niveaux, matériels et logiciels. Mais ça ne fait pas tout. Je limite les extensions que j’utilise, et celles que j’utilise sont dans l’ensemble de qualité, pas trop lourdes (une extensions pour une tâche), certaines fonctions ont été intégrées dans le thème, qui a également été choisi pour ne pas être trop lourd. La taille de chaque page est contrôlée pour ne pas être lourde à charger même sur une connexion un peu souffrante (j’ai démarré le blog quand j’habitais encore chez ma mère, donc je fais toujours attention à ça).

J’ai fait quelques réglages sur PHP histoire de bosser comme il faut en mémoire vive (taille confortable pour l’opcache entre autres), pareil pour la base de données, qui a finalement eu le plus de boulot : pools innodb, index supplémentaires, écart sur la conformité CRUD… Et donc Redis, dans lequel WordPress stocke le contenu de plusieurs objets, articles, commentaires, pour éviter de refaire les requêtes en base de données, certaines étant particulièrement peu efficaces et peu optimisables.

Et… C’est à peu près tout, mais faut dire que c’est déjà beaucoup plus que ceux qui font un « apt install nginx php mariadb-server » et qui mettent leur site en ligne 10 minutes plus tard sans plus de configuration.

Pourquoi le site à qui il est comparé peut-il être plus lent ?

Le site en question est hébergé sur un Synology DS1515+. Il est propulsé par un Intel Atom C2538 qu’on aurait aimé avoir dans des laptops plutôt que les bousasses grand public qu’on a subi dans des netbooks pendant des années. Il est accompagné de 16Go de RAM (quand la fiche technique annonce un max supporté de 6Go, mais c’est pas grave), et la grappe de stockage fait 40To et composée de disques à 7200 tours par minute avec 256Mo de cache.

Pas du matos de merde donc, mais en dehors du stockage, on a un CPU bien moins puissant que ma grosse bertha, mais dont la principale particularité est de consommer 4 fois moins. On a rien sans rien. Mais la puissance brute n’est pas seule responsable d’un éventuel écart. Si on se réfère à ce comparatif de CPUBoss, le support d’extensions de jeu d’instructions est inexistant ou presque sur l’Atom, et ça peut avoir des conséquences importantes sur plusieurs points de fonctionnement de PHP (compilation JIT), MariaDB, et du serveur web (s’il y a du HTTPS une partie peut être gérée par le CPU via AES-NI, c’est pas mal même si c’est pas le but premier de l’intégration du jeu d’instructions). Ensuite on parle d’un NAS, et donc, la connexion qui permet d’accéder au site est certainement plus légère que celle que me fournit OVH. En particulier au niveau de l’upload, et là, y’a pas de mystère, c’est pas en France sur des connexions grand public qu’on égalera une connexion d’un datacenter, les rares qui auront droit à du vrai FTTH avec un upload qui soit pas misérable vont se compter en dessous de la dizaine de pourcents (soit au delà de 200Mbps, je sais, mais je pourrais faire un article complet sur les raisons de ce palier qui parait hallucinant).

Et un autre point qui pourrait être finalement plus important que les autres : la version et la configuration des composants. Que ce soit Nginx, PHP, MariaDB (j’ai pas encore profondément mis les mains dans Redis mais j’ai du taf pour sûr), j’ai passé un peu de temps à régler chaque composant, à analyser un peu son comportement, faire des choix par rapport à mon usage. Concernant Nginx, ça tient d’abord aux nombre de processus (workers), et au nombre de connexions absorbables par ceux-ci, plus un mode HTTP2 s’il est exploitable par les navigateurs. Pour PHP, la version 7 est vraiment un coup de fouet par rapport aux précédentes, et le mode de fonctionnement d’FPM, les modules installés, la quantité de mémoire utilisée pour certains d’entre eux a été analysée. Pour MySQL/MariaDB, idem, 10.0 apporte déjà son lot d’améliorations de performances, et l’utilisation intensive de mysqltuner m’a permis de faire pas mal de corrections sur InnoDB pour en tirer le maximum. Enfin, si je n’avais pas les outils de bases comme htop, iftop, iotop, pour analyser en temps réel le comportement de la machine, j’aurais certainement raté quelques éléments.

Car vous pourrez disposer de toute la puissance brute que vous voulez, ça pourra masquer de grosses erreurs de configuration pendant un temps, mais ça ne fera pas de miracles non plus. C’est une sacrée recette de cuisine qu’on a là, et malgré le peu d’ingrédients à y inclure, on est un peu au delà de la méthode couper/foutre.

WordPress est-il le bon outil ?

Beaucoup pensent qu’on peut tout faire avec WordPress, et que c’est pour ça qu’il est utilisé par plus d’un quart des sites web référencés par les moteurs de recherche. J’ai tendance à penser que non, sinon il y aurait encore plus de monde dessus et bien moins de technologies et de moteurs pour construire des applications web dans différents langages. J’ai pu voir du WordPress pour présenter un site vitrine, un blog en tant qu’annexe d’un autre site,  une plateforme de commerce (j’en ai un qui passe en prod fin mars d’ailleurs), un moteur d’API pour une application écrite en Javascript sur une page HTML à part — un usage curieux tant les outils pour construire des API plus légères sont légions et bien documentés. Pire, j’ai vu le backoffice d’un WordPress multisites torturé pour en faire un intranet (hébergé sur AWS d’ailleurs, on notera l’ironie de « l’intra » dans ce cas), ce qui occasionne régulièrement des problèmes de fonctionnement, certaines tâches n’étant pas taillées pour fonctionner en mode web. Un autre tente de construire une sorte de réseau social, mais il est déjà acté que finalement WordPress va devenir trop limitant, aussi bien pour les performances que les fonctionnalités.

Bref pour chacun de ces usages, il y a certainement des outils plus adaptés que WordPress. Dans le cadre de mon contact, après avoir visité le site il n’y a rien à redire dans le rôle qu’il tient, c’est le bon outil bien que d’autres auraient pu tout aussi bien convenir (SPIP, Pluxml…). Le reste peut donc venir d’un ou de plusieurs des éléments que j’ai mentionné plus haut, et je vais donc reprendre le boulot par mail ou un autre canal pour qu’on essaie de tirer la quintessence de son installation. Et vous, vous avez maintenant des billes pour chercher d’où peut venir votre problème. D’ailleurs, j’ai peut-être oublié des choses, auquel cas, juste en dessous il y a un autre outil bien utile et adapté, les commentaires 😉