Combien de sites WordPress un même nœud peut-il servir avant que la mémoire, pas le processeur, devienne le facteur limitant ? C’est la question posée par un hébergeur qui prépare le remplacement d’un parc de serveurs mutualisés vieillissants, chacun hébergeant entre 300 et 500 sites à faible trafic individuel mais à forte densité.
Ce comparatif met face à face OpenLiteSpeed et nginx, sur ce cas précis de densité élevée plutôt que de trafic élevé sur un site unique. Apache n’entre pas dans ce match : sa consommation mémoire par processus le disqualifie d’emblée sur ce type de topologie, et la comparaison a déjà été faite ailleurs.
Le cache intégré change la donne pour le mutualisé
OpenLiteSpeed embarque un cache de pages au niveau du serveur web lui-même, configurable par vhost via des règles de réécriture ou, plus simplement, via l’extension LSCache côté WordPress. Ce cache vit dans le même processus que le serveur web, sans dépendre d’une brique supplémentaire comme Varnish ou un cache d’objets Redis partagé.
Avec nginx, le cache de pages passe soit par le module proxy_cache natif, soit par une extension comme FastCGI Cache Purge côté WordPress pour l’invalidation ciblée. Le mécanisme fonctionne bien, mais sur un mutualisé de plusieurs centaines de vhosts, chaque zone de cache proxy_cache_path doit être dimensionnée et isolée par site, ce qui alourdit la configuration générée dynamiquement à chaque création de compte.
Consommation mémoire par worker, le critère qui a tranché
Sur le nœud de test, 400 sites WordPress ont été répliqués avec des jeux de contenus réalistes (entre 200 et 2 000 articles chacun), exposés sous deux configurations identiques en ressources CPU et RAM allouées, l’une pilotée par OpenLiteSpeed, l’autre par nginx associé à PHP-FPM en pools mutualisés par groupe de sites.
| Critère | OpenLiteSpeed | nginx + PHP-FPM |
|---|---|---|
| Mémoire résidente au repos (400 sites) | Plus faible, cache et exécution PHP dans un socle commun (LSAPI) | Plus élevée, un ensemble de workers PHP-FPM par groupe de pools |
| Cache de pages | Intégré, activable par vhost sans brique tierce | Nécessite proxy_cache ou une brique externe type Varnish |
| Compatibilité configurations existantes | Traduit les .htaccess Apache, migration facilitée | Réécriture manuelle des règles de chaque vhost |
| Écosystème de documentation | Plus restreint, communauté plus petite | Très large, nginx étant un standard de facto |
La complexité de migration ne doit pas être sous-estimée
Le point qui a le plus surpris l’équipe de test n’est pas la performance brute, mais l’effort de migration. OpenLiteSpeed sait interpréter une bonne partie des règles .htaccess existantes, ce qui simplifie grandement la reprise d’un parc historiquement construit sur Apache. Chaque site mutualisé venant avec ses propres règles de réécriture accumulées au fil des années, cette compatibilité a fait gagner plusieurs semaines de travail de conversion manuelle par rapport à une bascule directe vers nginx.
En contrepartie, la communauté et la documentation disponibles autour de nginx restent nettement plus larges. Un incident de configuration nginx trouve presque toujours une réponse documentée ; un comportement inattendu d’OpenLiteSpeed demande plus souvent de fouiller le forum officiel du projet ou de tester directement.
Ce que la densité change concrètement
- À trafic global équivalent, OpenLiteSpeed a permis de tenir environ un tiers de sites en plus sur le même nœud avant saturation mémoire, dans ce test précis.
- Le gain vient surtout du cache intégré, qui évite de maintenir des pools PHP-FPM actifs pour des pages qui, en mutualisé à faible trafic, sont majoritairement servies depuis un cache.
- Sur un site à fort trafic individuel, l’écart se resserre nettement : la question posée ici concerne spécifiquement la densité, pas la performance d’un site isolé sous forte charge.
Verdict pour un hébergeur qui dimensionne un nœud mutualisé
Pour un parc neuf, sans passif de configuration Apache à reprendre, OpenLiteSpeed apporte un avantage mémoire réel sur ce cas de figure précis de haute densité à faible trafic unitaire. Pour un parc existant déjà opéré sous nginx, avec une équipe formée et une base de connaissance interne solide, le gain mémoire ne justifie pas forcément une migration complète, sachant que la charge opérationnelle d’apprentissage d’un nouveau serveur web n’est jamais négligeable sur un parc de production.
Le choix d’un serveur web pour un mutualisé ne se limite jamais aux benchmarks CPU : la mémoire consommée pour maintenir plusieurs centaines de contextes actifs pèse davantage sur la capacité réelle du nœud.
Notre verdict
OpenLiteSpeed a montré, sur ce test à 400 sites, une meilleure tenue mémoire grâce à son cache intégré et à sa capacité à absorber des configurations héritées d’Apache. nginx conserve l’avantage de la maturité documentaire et d’une base d’exploitants immense, un critère qui pèse lourd au moment de recruter et de former une équipe d’exploitation. Le choix dépend donc moins de la performance pure que du passif technique du parc à reprendre et de la disponibilité de compétences internes sur l’un ou l’autre serveur.
