Le socle technique actuel du blog

Twitter Facebook Google Plus Linkedin email

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 😉

 

6
Poster un Commentaire

avatar
5 Comment threads
1 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
4 Comment authors
LolYangccoolzwindlerl'@nar geekNordine Recent comment authors
  Subscribe  
plus récents plus anciens
Me notifier des
LolYangccool
Invité

Bonsoir, Je suis la personne concerné qui a donc envoyé ce fameux mail. Je tenais à remercier Seboss pour cet article, et à réagir à certains points. Comme expliqué par mail, la connexion est largement moins rapide que les 500Mb/s du serveur qui héberge ce blog, puisque je suis à 60Mb/s en down et 15Mb/s en up. Je pense que pour mon petit site, ça devrait être largement suffisant (Je ne fais pas des milliers de visites chaque jour…). Concernant les 16Go de RAM, je confirme que mon serveur a bien 16Go de RAM, upgradé par mes soins. En effet,… Read more »

Nordine
Invité
Nordine

Salut,
Merci pour ce super article. Il va me donner des idées pour mon futur blog.
J’ai une question cependant : As-tu pensé aussi à mettre en place un CDN en front (genre CloudFlare ou autre) ? Histoire de sécurisé encore un peu plus et d’avoir plus de réactivité pour les lecteurs. De plus cela soulagera aussi le serveur (même s’il est bien taillé).
Car justement dans le cas de ton lecteur, un CDN peut pallier à une connexion réseau faible aussi.

Voilà.
Nono.

LolYangccool
Invité

Oui mais je souhaite rester propriétaire de mes données 😉
Mes données restent chez moi. 😉
Puis bon, ma connexion réseau est suffisante pour les quelques 10 aine de pages vues par jour que je fais, je pense.
Le jour où ça ne suffira vraiment plus, je repasserais le site sur le VPS que je loue à OVH, mais le plus tard sera le mieux.

l\'@nar geek
Invité

C’est vrai que pour du wordpress, ça tourne très bien. Mais j’avoue que je préfére toujours blogotext ou pluxml 😀
Dans mon bts, on faisait du wordpress à 17 dans la salle, le serveur wamp était asphyxié…

zwindler
Invité

Hello, J’héberge un blog avec des technos/une infra similaire (kimsufi i7 + proxmox) et même si on peut toujours faire mieux en perf’ (faut que je fasse le minifying du JS et que je vire une extension gourmande), j’ai pas rencontré de gros problèmes (pas de l’ordre de ceux que j’avais en mutualisé avant d’administrer moins même). Typiquement j’ai eu pas besoin d’un redis et j’ai alloué moins de ressources. Je me dis que c’est peut être des questions qu’on se pose quand on génère plus de trafic ? Je tourne à 500-1000 vues par jour, tu es peut être… Read more »

LolYangccool
Invité

J’ai changé de serveur, en test pour le moment.
http://geekonweb.fr/le-socle-technique-actuel-du-site-en-test.html

Ça tourne mieux, du coup. Ça consomme plus aussi. Comme l’a dit Seboss, on a rien sans rien. 😉