
💡 Comment réduire la charge du serveur et accélérer WordPress avec Memcached
Un site WordPress sans mise en cache ressemble à un moteur qui redémarre à froid à chaque feu rouge. Un visiteur arrive sur une page, PHP l’assemble intégralement, en interrogeant la base de données 30 à 60 fois. Dix visiteurs simultanés, c’est trois cents requêtes. Cinquante visiteurs déclenchent une avalanche qui fait chuter les connexions du serveur plus vite que vous n’avez le temps de taper une commande dans la console.
Le problème ne vient pas de WordPress lui-même. L’assemblage dynamique des pages est par nature très peu efficient; presque tous les CMS fonctionnent ainsi. La solution a fait ses preuves sur des projets à forte charge: le cache objet en RAM via Memcached. Une couche Memcached correctement configurée transforme un serveur qui s’étouffe avec cinquante utilisateurs simultanés en une machine qui en gère des centaines sans le moindre ralentissement du temps de réponse.
Nous allons parcourir l’intégralité du cycle de mise en place: de l’installation du démon jusqu’à un test de charge qui montre la différence en chiffres. Toutes les commandes ont été testées sur Ubuntu 22.04/24.04 et AlmaLinux 9, et sont compatibles avec PHP 8.2 à 8.5.
💡 Aperçu rapide:
- Installer le démon Memcached et le lier à localhost pour des raisons de sécurité
- Compiler l’extension PHP memcached via PECL pour votre version de PHP
- Placer le fichier object-cache.php fourni par Automattic dans le répertoire wp-content
- Installer Batcache et configurer advanced-cache.php pour le cache de pages
- Vérifier les en-têtes de réponse via les DevTools du navigateur
- Lancer un test de charge avec k6 et comparer les résultats avant/après
Qu’est-ce que Memcached et pourquoi votre WordPress en a besoin
Memcached est un démon qui stocke des données et des objets dans la RAM du serveur. Contrairement aux caches basés sur des fichiers (WP Super Cache, W3 Total Cache, WP Rocket), qui écrivent du HTML prêt à l’emploi sur le disque, Memcached intervient un niveau plus bas: les résultats des requêtes de base de données, les menus assemblés, les widgets et les paramètres du site résident en RAM et peuvent être récupérés en microsecondes, sans reconstruction.
Concrètement, voici ce que cela donne. Une page WordPress typique sans cache génère 30 à 60 requêtes vers MySQL. Avec 50 visiteurs simultanés, la base de données reçoit entre mille cinq cents et trois mille requêtes, et le processeur passe en mode dégradé. Memcached intercepte l’écrasante majorité de ces requêtes au niveau de la RAM: la base de données est au repos, le processeur reste disponible et le serveur répond instantanément.
Techniquement, Memcached fonctionne sur des paires clé-valeur. La clé est un hash de la requête SQL; la valeur est le résultat sérialisé. Lorsque WordPress assemble à nouveau la même page, il demande d’abord à Memcached: «As-tu cette clé?» et reçoit presque toujours une réponse immédiate, sans aucun accès disque.
Cette technologie est apparue en 2003 au sein de LiveJournal pour résoudre des problèmes de charge extrême sur la base de données. Aujourd’hui, WordPress.com, Wikipedia, Twitter et des milliers de projets à forte charge tournent avec Memcached. C’est une solution mature, stable et prévisible: exactement ce dont la production a besoin.
Installation du démon Memcached
Nous allons couvrir deux scénarios principaux: Ubuntu (22.04/24.04) avec apt et AlmaLinux / Rocky Linux 9 avec dnf. Adaptez les commandes à votre distribution.
Sur Ubuntu:
1 sudo apt update && sudo apt install memcached libmemcached-tools -y
Sur AlmaLinux / Rocky Linux 9:
1 sudo dnf install memcached libmemcached -y
Après l’installation, le démon démarre automatiquement. Vérifiez:
1 systemctl status memcached
Par défaut, Memcached écoute sur le port 11211 sur toutes les interfaces réseau. C’est une faille de sécurité: votre cache est accessible à toute personne pouvant atteindre ce port depuis l’extérieur. Par conséquent, liez d’abord le démon à localhost.
Ouvrez le fichier de configuration (/etc/memcached.conf sur Ubuntu, /etc/sysconfig/memcached sur AlmaLinux) et assurez-vous que la ligne -l 127.0.0.1 est présente et n’est pas commentée. Redémarrez le démon:
1 sudo systemctl restart memcached
Compilation de l’extension PHP via PECL
Le démon seul n’accélérera pas WordPress; vous avez besoin d’un client PHP qui apprend à PHP à communiquer avec Memcached. Installez l’extension memcached (attention: spécifiquement memcached avec la lettre d, et non memcache). Cette dernière a été retirée de PHP à partir de la version 8.0 et ne doit plus être utilisée.
Sur Ubuntu, installez d’abord les outils de compilation. Adaptez la version de PHP: php8.4-dev, php8.3-dev ou php8.2-dev:
1 sudo apt install php8.4-dev php-pear libmemcached-dev pkg-config make gcc -y
Ensuite, compilez l'extension:
1 sudo pecl install memcached
Sur AlmaLinux / Rocky Linux 9, l'ensemble est similaire:
1 sudo dnf install php-devel php-pear libmemcached-devel make gcc -y 2 sudo pecl install memcached
Après la compilation, l'extension doit être enregistrée dans PHP. Créez un fichier INI:
1 echo "extension=memcached.so" | sudo tee /etc/php/8.4/mods-available/memcached.ini 2 sudo phpenmod memcached
Sur AlmaLinux, le chemin sera différent: /etc/php.d/memcached.ini.
Si vous travaillez dans Plesk Obsidian, voici la commande pour recharger les gestionnaires PHP après l'installation de l'extension:
1 plesk bin php_handler --reread
Vérifiez que l'extension est bien chargée:
1 php -m | grep memcached
La sortie doit contenir memcached. Si elle est vide, vérifiez le chemin du fichier INI et redémarrez PHP-FPM: sudo systemctl restart php8.4-fpm.
Connecter WordPress à Memcached
Le démon est installé, l'extension PHP est chargée. Vous devez maintenant connecter WordPress à Memcached au niveau applicatif.
Le standard de facto aujourd'hui est le drop-in officiel d'Automattic: wp-memcached sur GitHub. Il est écrit par les mêmes développeurs qui maintiennent Batcache et WordPress.com, et il fonctionne correctement avec PHP 8.x (y compris les versions 8.4 et 8.5).
Copiez le fichier object-cache.php du dépôt dans le dossier /wp-content/ de votre site. WordPress le détectera automatiquement et commencera à utiliser Memcached comme backend de cache d'objets, sans plugins supplémentaires.
Si le port Memcached diffère de celui par défaut (11211), ajoutez ce qui suit à wp-config.php:
1 $memcached_servers = array( 2 array( '127.0.0.1', 11211 ) 3 );
Cache de pages: Batcache
Le cache d'objets est une moitié du travail. L'autre moitié consiste à mettre en cache les pages HTML prêtes afin que PHP ne s'exécute pas du tout pour les visiteurs anonymes. C'est là qu'intervient Batcache, un plugin d'Automattic qui stocke les pages générées dans le même Memcached.
Le principe est simple. Un visiteur arrive sur le site; Batcache vérifie s'il existe une copie HTML prête de cette page dans Memcached. Si c'est le cas et qu'elle n'a pas expiré, il la sert instantanément, en contournant toute la chaîne PHP et MySQL. Sinon, ou si le visiteur est connecté, la page est générée à nouveau et simultanément sauvegardée dans le cache pour les visites suivantes.
Installation:
Téléchargez l’archive depuis wordpress.org, extrayez-la et envoyez le fichier advanced-cache.php à la racine de /wp-content/. Ouvrez ensuite wp-config.php et ajoutez la ligne qui active la mise en cache:
1 define( 'WP_CACHE', true );
Envoyez le fichier batcache.php dans /wp-content/plugins/ et activez l’extension dans le panneau d’administration.
À l’intérieur de advanced-cache.php, une douzaine de paramètres environ sont documentés sous forme de commentaires. Les plus utiles: max_age (durée de vie d’une page en secondes, 300 par défaut, soit 5 minutes), seconds (intervalle entre deux régénérations d’une même URL) et unique (ne pas mettre en cache séparément les différents User-Agents). Pour la plupart des sites, les valeurs par défaut conviennent; ne les modifiez que lorsque vous comprenez pourquoi.
Une nuance importante: vérifiez que define( 'WP_CACHE', true ) apparaît AVANT la ligne require_once ABSPATH . 'wp-settings.php' dans wp-config.php. Placée après, la mise en cache ne s’activera pas et WordPress l’ignorera silencieusement.
Vidéo: installation et configuration de A à Z
La théorie pose les bases, mais les commandes en console, on les retient mieux en les voyant une fois. Cette vidéo couvre le cycle complet de mise en place du cache objet pour WordPress avec Redis et Memcached, de l’installation du démon jusqu’à la vérification du résultat:
Vérifier que Memcached fonctionne
Le meilleur test est un test pratique. Ajoutez un en-tête personnalisé dans advanced-cache.php afin de voir visuellement si la page a été servie depuis le cache ou générée à nouveau.
Trouvez cette ligne dans advanced-cache.php:
1 var $headers = array();
Remplacez-la par:
1 var $headers = array( 'memcached' => 'activated' );
Ouvrez maintenant les DevTools de votre navigateur (F12), allez dans l’onglet Réseau et rechargez la page plusieurs fois. Dans les en-têtes de réponse, vous verrez un champ memcached: activated, ce qui signifie que Batcache a fonctionné et que la page est arrivée au client directement depuis la RAM.
Une méthode complémentaire passe par la ligne de commande du serveur. Consultez les statistiques du démon:
1 echo "stats" | nc 127.0.0.1 11211
Dans la sortie, cherchez get_hits et get_misses. Si get_hits augmente lorsque vous rafraîchissez les pages du site dans le navigateur, Memcached sert bien les objets mis en cache.
Test de charge: des chiffres, pas des impressions
Memcached révèle sa vraie valeur sous pression. Le test d’origine sur un serveur doté d’un cœur et de 512 Mo de mémoire a produit un contraste saisissant: sans Memcached, le serveur tombait après 15 secondes avec 50 utilisateurs simultanés; avec Memcached, il a tenu plus de 400 utilisateurs pendant 50 secondes sans une seule erreur. Ce n’est pas de la magie, mais de la physique: quand le CPU ne passe pas ses cycles à réassembler les mêmes pages, il sert de nouveaux visiteurs.
Pour un autotest aujourd’hui, on utilise des outils modernes. L’un des plus pratiques est k6 de Grafana (open source, s’exécute avec une seule commande). Un test de base:
1 k6 run --vus 100 --duration 30s http://your-site.com/
100 utilisateurs virtuels pendant 30 secondes. Comparez les résultats avec Batcache désactivé (commentez WP_CACHE) et activé; la différence de réponses réussies et de latence médiane se mesurera en ordres de grandeur.
Pour une vérification rapide sans installer de logiciel, l’outil web Loader.io fonctionne bien; le niveau gratuit autorise jusqu’à 10 000 clients par test, ce qui est largement suffisant pour la plupart des sites.
Redis ou Memcached: lequel choisir
La question qui se pose inévitablement est: pourquoi pas Redis? Les deux sont des entrepôts clé-valeur en mémoire; les deux fonctionnent avec WordPress via des drop-ins. La réponse courte: pour la mise en cache pure, Memcached est plus simple et plus rapide; pour tout le reste, Redis.
Comparons l’essentiel:
Critère | Memcached | Redis |
|---|---|---|
Modèle de données | Chaînes uniquement | Chaînes, listes, ensembles, hachages, données géo, pub/sub |
Multi-threading | Utilise tous les cœurs nativement | Principalement mono-thread |
Persistance | Aucune (pur in-memory) | RDB/AOF (sauvegarde sur disque) |
Écosystème WordPress | Automattic/wp-memcached + Batcache | Redis Object Cache (plus de 400 000 installations) |
Complexité d’installation | Minimale | Légèrement plus élevée |
Vidage du cache au redémarrage | Complet (mais se réchauffe en quelques minutes) | Peut être préservé |
Pour la mise en cache des objets WordPress, le couple clé-valeur en chaînes est plus que suffisant. Les types de données supplémentaires de Redis ne sont pas nécessaires ici. Sur les opérations get/set, les deux sont limités par le débit réseau plutôt que par le CPU; toutes choses égales par ailleurs, ils sont à égalité. Memcached l’emporte sur le multi-threading: il utilise tous les cœurs du CPU nativement, tandis que Redis conserve une architecture majoritairement mono-thread.
Choisissez Redis si vous stockez également des sessions, des files de tâches ou si vous avez besoin de persistance. Pour la mission «accélérer WordPress et décharger la base de données», Memcached apporte des résultats plus rapidement et avec moins de pièces mobiles.
⁉️🤔 Questions fréquentes
Ai-je besoin de Memcached sur un hébergement mutualisé?
Sur la plupart des offres mutualisées, Memcached est indisponible: les hébergeurs ne donnent pas accès au démon au niveau du serveur. En revanche, si votre offre inclut un VPS ou un serveur dédié, l’installation prend 10 à 15 minutes et produit l’un des gains de vitesse les plus notables parmi toutes les optimisations WordPress. Vérifiez les capacités de votre offre dans le panneau de contrôle ou demandez au support de l’hébergeur.
Batcache ou WP Rocket: lequel est le meilleur?
WP Rocket est un outil multifonction qui gère la mise en cache des pages (sur fichier), l’optimisation CSS/JS et le lazy loading. Batcache est un outil ciblé, spécifiquement conçu pour la mise en cache de pages via Memcached. Ils ne sont pas concurrents; ils se complètent: Batcache travaille au niveau du serveur et sert les pages sans lancer PHP, tandis que WP Rocket opère au niveau applicatif. En pratique, on utilise souvent les deux: Batcache pour les visiteurs anonymes, WP Rocket pour une optimisation fine.
Comment vider le cache Memcached?
La méthode la plus simple consiste à redémarrer le démon:
sudo systemctl restart memcached. Le cache se vide complètement et recommence à se réchauffer lors des visites suivantes. Pour une suppression ciblée, utilisez l’extension Query Monitor: elle affiche le contenu du cache objet et permet de vider des clés individuelles. Il existe aussi une option en console:echo "flush_all" | nc 127.0.0.1 11211.
Pourquoi le site n’a-t-il pas accéléré après l’installation d’object-cache.php?
La raison la plus fréquente est que l’extension PHP ne s’est pas chargée. Vérifiez avec
php -m | grep memcached. Si la sortie est vide, contrôlez le chemin du fichier INI et redémarrez PHP-FPM. La deuxième raison courante:object-cache.phpn’a pas été copié dans/wp-content/ou l’a été avec des erreurs de droits (il doit être lisible par l’utilisateur qui exécute PHP). Troisième raison: le démon Memcached n’est pas en cours d’exécution; vérifiez avecsystemctl status memcached.
Memcached entre-t-il en conflit avec OPcache?
Non, ce sont des couches différentes. OPcache met en cache le bytecode PHP compilé et accélère le démarrage de l’interpréteur. Memcached met en cache les données applicatives: les résultats des requêtes à la base de données. Ils interviennent à des étapes distinctes du traitement de la requête et se complètent bien. En production, il est recommandé d’utiliser les deux.
Peut-on utiliser Memcached sur plusieurs serveurs?
Oui, c’est l’un des scénarios principaux. Dans la configuration
$memcached_servers, vous pouvez lister plusieurs adresses IP de démons Memcached, et le client répartira automatiquement les clés entre eux. Pour WordPress, le drop-inobject-cache.phpgère cela: il prend en charge un pool de serveurs nativement.
Faut-il installer Memcached sur votre serveur
Installer Memcached n’est pas une solution miracle, mais c’est l’une des étapes les plus efficaces de l’optimisation WordPress. Si votre site tourne sur un VPS ou un serveur dédié et que vous voulez qu’il absorbe une multiplication du trafic sans changer de matériel, installez-le. Dix à quinze minutes de travail en console, et la base de données cesse d’être un goulet d’étranglement.
Si le site est sur un hébergement mutualisé sans accès au démon, envisagez Redis (plus souvent proposé) ou la mise en cache sur fichier via WP Rocket. Si vous êtes déjà sur un VPS, ouvrez le terminal et suivez les étapes du récapitulatif rapide ci-dessus. Vous verrez le résultat dès votre premier test de charge.



