Où regarder pour optimiser les performances d’un site Web ?

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

J’ai déjà abordé plusieurs fois des moyens de grapiller quelques points en performance, notamment pour ce blog. Mais justement, de quoi a-t-on besoin pour un tel blog, et quelles sont les options qui s’offrent à nous pour en améliorer la réactivité ?

C’est un peu de la vulgarisation, même si je rentre un peu dans les détails ce coup-ci. Bref, pour un blog comme WordPress, il vous faut au grand minimum trois composants :

• un serveur Web, ou serveur HTTP, du nom du protocole en question
• un interpréteur PHP, le langage de programmation utilisé côté serveur pour écrire WordPress
• une base de données MySQL destinée à stocker et organiser tout le contenu du site

Quand vous optez pour un hébergement « tout-en-un », dit mutualisé, vous ne vous occupez que de votre site, pas de son infrastructure derrière.

Mais souvent quand vous débutez et que vous n’en êtes qu’au stade de la découverte, on vous propose d’installer tout ça sur une seule et même machine, pourquoi pas votre ordinateur, le temps de se faire la main (parfois avec des outils comme XAMPP). Ce n’est absolument pas un problème en soit, d’un côté c’est même déjà bénéfique puisque les composants communiqueront entre eux très rapidement. Les plateformes d’hébergement mutualisées, pour des raisons qu’on verra après, auront tendance à séparer les composants sur des machines différentes.

Au début, vous ne verrez pas de grande différence. Mais avec le temps, le site, plus populaire, pourra commencer à « ramer ». Soit le site devient simplement lent (même pour vous), soit carrément des erreurs apparaissent, un peu comme celle-là :

Les tutos pour débutants, un bon départ, mais loin d’être optimal

En effet, souvent, notamment sous Linux, on vous présente d’emblée la famille Apache/MySQL/PHP, le fameux LAMP. Avec PHP en module d’Apache, ce qui l’oblige à utiliser le mode mpm-prefork. Apache est le serveur Web, MySQL la base de données, et PHP… bon voilà quoi. C’est cool, ça s’installe en deux minutes et après paf, ça fait des Chocapic. Enfin plutôt, ça marche pratiquement « out-of-the-box », tant qu’on a pas à gérer un trafic de ouf.

Car c’est là un des problèmes récurrents : les admins en herbe qui se limitent à leur premier tuto vont très vite rencontrer des problèmes, que ce soit de performance (ce qui nous intéressera le plus aujourd’hui), ou de sécurité. En effet, à l’image de n’importe quel logiciel installé sur votre ordinateur, un serveur peut être exploité à de mauvaises fins s’il est configuré et utilisé avec les pieds.

Comme je l’ai dit, aujourd’hui il est question de performances, et donc parfois d’alternatives. Car on le verra, le tryptique classique est loin d’être le plus à même d’absorber les fortes charges et les applications complexes. Reprenons la liste dans l’ordre.

Apache

Apache a beau être le plus répandu des serveurs HTTP, ne pas se pencher sur sa configuration, voire carrément son mode de fonctionnement, peut vous faire passer à côté de sa puissance. En effet, les réglages par défaut, du moins sous Debian, sont « conservateurs », car il est impossible de présumer de la puissance de la machine sur laquelle on l’installe. Sans parler du choix du mode d’exécution de PHP, qui imposera un mode de fonctionnement d’Apache au détriment d’un autre. Allouer plus de ressources au serveur Web est évidemment un des premières pistes à considérer.

Les aventureux ou ceux à la recherche de performances plus importantes à machine égale pourront se pencher sur Nginx. C’est un serveur web d’origine russe, certes, mais surtout open-source. Il possède de nombreuses fonctionnalités, par contre il est moins modulaire qu’Apache. Il conviendra de regarder de plus près, et de tester profondément vos applications avant de basculer sur ce serveur. En tout cas, sachez qu’il est utilisable sans problème avec WordPress.

PHP

Le langage PHP a déjà pas mal d’années de services (1994, soit trois ans après le HTTP), mais il a continué d’évoluer et reste l’un des plus utilisés pour de nombreuses applications. Il est très facile de s’y mettre, la documentation s’est grandement améliorée. Les tutos sont nombreux, les bouquins aussi. De nombreuses bibliothèques et frameworks sont disponibles pour vous faire gagner du temps.

Il s’exécute côté serveur, et la plupart du temps, vu qu’on suit souvent les mêmes tutos (puisqu’on cherche tous sur Google…), en module d’Apache. Ce qui veut dire que l’exécution de l’un aura tendance à dégrader celle de l’autre s’il défaille. Un des premiers moyens d’en améliorer l’exécution, en dehors de l’allocation de ressources à l’image d’Apache, et que j’ai déjà abordé, c’est FPM, pour FastCGI Process Manager. Cette machine d’exécution est plus rapide que le module, et les versions plus récentes (5.5 et suivantes) incluent un cache d’instructions. Ce qui veut dire que si un même code est demandé souvent, son résultat sera stocké en mémoire et directement resservi sans être réinterprété.

Pour les fous furieux (vu les performances qu’il donne), HHVM est un choix avisé. J’en ai parlé dans l’article de mes expérimentations, l’outil développé par Facebook est rapide, très rapide. Mais il ne pourra pas convenir à toutes les situations. À tester longuement donc.

MySQL

MySQL est un bon serveur de bases de données. S’il n’est pas nécessairement le meilleur, il est le plus répandu, car très accessible. À l’image d’Apache et de PHP, les documentations sont nombreuses, et la connexion très facile avec PHP en ont fait rapidement un choix dans l’hébergement de pages dites dynamiques. Pour l’instant, malgré le rachat par Oracle et les polémiques sur sa gouvernance (Oracle et polémique, un pléonasme ?), le logiciel reste open-source, et pour l’instant gratuit à l’usage.

De la même manière qu’Apache, il est possible de modifier nombre de paramètres du serveur pour optimiser son fonctionnement avec votre base. La base étant principalement opérée depuis le disque dur, un support de stockage rapide est préférable. Les hébergeurs ont tendance à opérer sur des SSD, qu’on sait déjà très, très rapide, et donc sur des machines à part, la communication passant alors par le réseau.

Le problème de la gouvernance par Oracle, c’est que les ajouts au niveau même du code du serveur sont souvent remises en question. Les ajouts peuvent aussi bien concerner les fonctionnalités que les performances. Au delà des problèmes que je vient d’évoquer, et des tarifs pratiqués pour le support technique, est apparu un fork, MariaDB, qui se veut le plus compatible possible avec l’original. On l’utilise avec le même langage SQL, mais est moins frileux quand il s’agit d’augmenter ses performances. De la même façon que l’original, il conviendra parfois de s’attarder sur ses paramètres pour en tirer la moelle. J’ai déjà abordé comment y passer, sans modifier les paramètres, on gagne déjà un peu en patate (rien de transcendant, mais ça peut déjà se sentir sur certaines applications).

Un élément qu’on oublie souvent : le serveur DNS

Aussi performante que puisse être votre installation, s’il vous faut deux secondes pour savoir que blog.seboss666.info est la machine 91.121.61.180, vous aurez l’impression que les pages mettent plus de deux secondes à charger, c’est mécanique. Personnellement, c’est OVH qui s’occupe de la gestion de la totalité du domaine seboss666.info, car je ne suis pas encore très à l’aise avec une gestion entièrement manuelle de ma zone.

Pour les plus chargés en pilosité donc, Bind ou Unbound font partie des morceaux de choix dans la gestion de son domaine. Unbound peut d’ailleurs aussi faire office de résolveur/cache DNS, je l’ai évoqué dans l’article sur un internet sain (bind aussi, notez bien).

Par contre, s’il y a une latence entre votre résolveur (ou celui de votre FAI, ou celui que vous avez paramétré,  peu importe), et celui d’OVH, qui a la réponse, y’a pas grand chose à faire. C’est pour ça que certains ont leur propre serveur DNS sur une machine puissante, voire sur la même machine que celle où est installé le site.

D’autres solutions pour les conservateurs ?

Quand on a pas la possibilité, ou la volonté d’utiliser des versions plus récentes, qu’on veut coller au max des dépôts de son installation par exemple, il existe malgré tout d’autres pistes à explorer. La principale, la plus évidente, est de changer de machine pour une plus performante à tous les points : disque, CPU, mémoire vive, bande passante… Mais ce n’est pas la seule possibilité, et d’autres protagonistes peuvent entrer en jeu.

Pour ceux qui veulent rester à PHP 5.4, APC est utilisable en tant que cache d’instructions. Il en existe d’autres, mais comme celui-ci fait partie de PHP, est proposé comme module dans Debian, il est facile d’accès.

À l’étape au dessus, on peut carrément utiliser un cache « global » comme Varnish. Il stocke en RAM les pages déjà générées, il faut donc faire attention à la quantité de mémoire disponible. Quand on demande une page qu’il connaît déjà, la resservir depuis le cache est très, très performant. Il fonctionne comme un « proxy » qui intercepte les requêtes HTTP pour vérifier leur présence en mémoire. Nicolargo en a déjà très bien parlé, donc je n’ai pas besoin d’en dire plus.

Et pour les aventuriers avec de gros bagages ?

Si on a pas peur d’emprunter des routes différentes, les choix sont nombreux. Les bases de données dites « NoSQL », comme MongoDB, sont populaires ces dernières années, et suivant les situations, plus rapides que les bases de données relationnelles. Des langages alternatifs comme Python, Ruby, ou pire, JavaScript (node.js), ont le vent en poupe pour certains types d’applications, comme les API (très utiles pour les services utilisables sur de nombreuses plateformes fixes et mobiles), mais aussi certains gestionnaires de contenu (il en existe même en Java, imaginez l’horreur). Un autre CMS, tel PluXml qui se passe de base de données et donc demandera plus d’attention côté stockage, peut s’avérer autant d’options à votre portée. Car avant tout, il s’agit de bien cerner vos besoins, vos envies, pour sélectionner la bonne solution.

Autant de choix peut paraître déroutant, mais c’est aussi une force dans le monde d’aujourd’hui. Et prendre un peu de temps pour vous documenter, tester, et préparer correctement le futur peut vous éviter d’en perdre quand il faudra corriger les problèmes.