Le réseau appartenait à une franchise immobilière : 300 sites, un par agence locale, tous basés sur le même thème et les mêmes extensions, gérés depuis une seule installation multisite. Le problème remonté n’était pas un incident ponctuel mais une dégradation progressive : les temps de réponse moyens avaient doublé en un an, sans qu’aucun changement de code majeur n’ait été identifié comme cause unique.
Ce retour d’expérience ne traite pas de l’administration du réseau au sens fonctionnel (gestion des rôles, création de nouveaux sites), mais uniquement des aspects performance qui expliquaient cette dégradation et du plan mis en place pour la corriger.
Premier constat : les tables partagées saturent
Certaines tables d’une installation multisite sont partagées entre tous les sites du réseau, notamment wp_users, wp_usermeta, wp_sitemeta et wp_blogs. Avec 300 sites et un total de près de 40 000 comptes utilisateurs cumulés (chaque agence gérant ses propres contacts commerciaux comme utilisateurs WordPress), la table wp_usermeta avait atteint plus de 2 millions de lignes, chaque requête de connexion ou de vérification de capacité déclenchant des lectures sur cette table commune à l’ensemble du réseau.
Deuxième constat : un cache d’objets mal segmenté
Le cache d’objets Memcached en place fonctionnait, mais son dimensionnement mémoire n’avait jamais été révisé depuis l’installation initiale, à l’époque où le réseau comptait 40 sites. Avec 300 sites actifs, le taux d’éviction (données expulsées du cache faute de place avant leur expiration naturelle) dépassait 30 %, ce qui signifie que près d’un tiers des lectures de cache retombaient sur la base de données malgré la présence théorique d’un cache d’objets persistant.
Ce diagnostic a été confirmé avec la commande de statistiques du client Memcached, qui affichait un ratio d’évictions anormalement élevé rapporté au nombre de get :
echo "stats" | nc localhost 11211 | grep -E "evictions|cmd_get|get_hits"Troisième constat : une tempête de cron synchronisée
Chaque site du réseau exécutait ses propres tâches planifiées via le mécanisme de wp-cron déclenché à chaque visite. Comme la plupart des agences recevaient l’essentiel de leur trafic aux mêmes heures de bureau, les tâches cron de nettoyage de transients et de génération de flux RSS s’exécutaient en rafale sur les mêmes intervalles horaires, créant des pics de charge CPU parfaitement synchronisés et prévisibles, visibles sur les graphiques de supervision toutes les heures pile.
Le plan de remise à niveau
- Désactivation du cron déclenché par visite au profit d’un vrai cron système, avec des horaires légèrement décalés site par site pour étaler la charge sur la durée plutôt que de la concentrer sur des créneaux fixes.
- Redimensionnement du cache d’objets Memcached, avec un passage de 512 Mo à 4 Go de mémoire allouée, ramenant le taux d’éviction sous les 2 %.
- Archivage des comptes utilisateurs inactifs depuis plus de deux ans vers une table séparée, réduisant
wp_usermetade 2,1 millions à 640 000 lignes actives. - Ajout d’un index composite sur
wp_usermeta(user_id, meta_key), absent dans l’installation d’origine malgré son usage massif par les vérifications de capacités sur chaque site du réseau.
Sur un multisite de cette taille, le réflexe à avoir en premier n’est pas de regarder le code de chaque site individuellement, mais les tables partagées par construction : elles subissent la charge cumulée des 300 sites, pas d’un seul.
Résultat mesuré
Trois mois après la mise en œuvre du plan, le temps de réponse moyen du réseau était revenu à un niveau inférieur à celui mesuré un an plus tôt, malgré une croissance continue du nombre d’agences actives sur la période. Le point le plus visible pour l’équipe technique du client a été la disparition complète des pics de charge horaires auparavant systématiques.
En résumé
Un multisite qui se dégrade progressivement, sans incident isolé identifiable, pointe presque toujours vers les ressources partagées par construction entre tous les sites du réseau : tables communes, cache d’objets unique, tâches cron synchronisées. Diagnostiquer ces trois axes en priorité, avant de se pencher sur le code spécifique d’un site individuel, aurait fait gagner plusieurs semaines d’investigation sur ce projet.
