Cette comparaison des gestionnaires PHP montre comment mod_php, CGI, FastCGI, PHP-FPM et LSAPI gèrent les Performance de votre hébergement, de la charge CPU aux latences de queue. Je vous explique concrètement quel choix faire pour WordPress, WooCommerce et les pics de trafic. Temps de chargement réduit et préserve en même temps les ressources.
Points centraux
- PHP-FPM Plus efficace que mod_php et FastCGI en termes d'évolutivité.
- LSAPI fournit les meilleures valeurs sur LiteSpeed.
- Isolation par utilisateur renforce la sécurité.
- OPcache et Redis réduisent les latences.
- P95/P99 montre une expérience utilisateur authentique.
Comment fonctionnent les gestionnaires PHP
Un gestionnaire PHP relie le serveur web à l'interpréteur et contrôle Processus, la mémoire et les E/S pour chaque requête. CGI lance un nouveau processus pour chaque requête et recharge les configurations, ce qui génère une surcharge et Latence augmenté. Les variantes modernes telles que FastCGI, PHP-FPM ou LSAPI maintiennent les workers en permanence disponibles et permettent ainsi de gagner du temps au démarrage, d'éviter les changements de contexte et d'économiser des cycles CPU. OPcache reste en mémoire, ce qui évite de devoir compiler le bytecode à chaque fois et accélère la réponse des pages dynamiques. Parallèlement, la gestion des processus détermine le nombre de requêtes simultanées autorisées, la définition des priorités et la manière d'amortir les pics de charge.
Comparaison directe des principaux gestionnaires
Le choix du gestionnaire détermine la Mise à l'échelle, le modèle de sécurité et les besoins en RAM d'une application. mod_php intègre PHP dans le processus Apache et offre des temps de réponse courts, mais souffre d'une faible Isolation entre les comptes. CGI sépare clairement les utilisateurs, mais coûte énormément de temps CPU par requête. FastCGI réduit la charge, mais reste moins efficace qu'un PHP-FPM bien réglé. LSAPI va encore plus loin lorsque LiteSpeed est utilisé et stabilise en particulier les latences de queue lors de nombreuses connexions simultanées.
| manipulateur | Performance | Sécurité | Besoin en RAM | Évolutivité | Scénario d'intervention |
|---|---|---|---|---|---|
| mod_php | Haute | Faible | Faible | Moyens | Petits sites, pics rares |
| CGI | Faible | Haute | Haute | Faible | Contenus statiques, tests |
| FastCGI | Moyens | Moyens | Moyens | Moyens | solution provisoire |
| PHP-FPM | Très élevé | Haute | Faible | Haute | Hébergement mutualisé, CMS |
| LSAPI | Le plus haut niveau | Moyens | Très faible | Très élevé | Trafic intense, commerce électronique |
PHP-FPM en pratique : processus, pools, réglage
PHP-FPM fonctionne avec des pools de travailleurs qui extraient les requêtes d'une file d'attente et ainsi Pics de charge amortir avec élégance. Je crée un pool distinct pour chaque site web afin que la configuration, les limites et le contexte utilisateur restent séparés et que les Sécurité augmente. Dans la pratique, les réglages adaptatifs tels que pm = dynamic ou ondemand sont rentables, car le nombre de processus actifs s'adapte à la demande. Il est essentiel de dimensionner correctement pm.max_children et les limites de temps afin que la file d'attente ne s'allonge pas et que des réserves de RAM restent disponibles. Pour commencer, je recommande de vérifier les paramètres de manière structurée ; j'explique ici les détails du réglage fin : Gestion des processus PHP-FPM.
LSAPI et LiteSpeed : performances optimales en cas de forte simultanéité
LSAPI conserve les processus PHP en mémoire et réduit les changements de contexte, ce qui permet de générer du contenu dynamique avec HTTP/3 et QUIC encore plus fluides. À pleine charge, la latence P95/P99 reste plus stable que celle de nombreuses alternatives, ce qui Expérience utilisateur visiblement amélioré. Je constate régulièrement davantage de requêtes par seconde et un TTFB plus court sur les pages boutique et contenu, en particulier lorsque OPcache et le cache serveur fonctionnent ensemble. L'avantage ne se manifeste pas seulement dans les valeurs moyennes, mais aussi dans les sessions simultanées, les sessions avec des échecs de cache et les workers PHP „ froids “. Pour comprendre la différence d'architecture, lisez la présentation générale sur LiteSpeed vs Nginx et décide ensuite du stack.
WordPress et WooCommerce : classer correctement les valeurs mesurées
Avec WordPress, j'obtiens des performances élevées avec PHP 8.2 sur FPM ou LSAPI. req/s, tandis que WooCommerce génère un peu moins de requêtes par seconde en raison des sessions, de la logique du panier et d'un accès plus important à la base de données. Le test n'est significatif que dans des conditions réalistes. Trafic avec des hits et des misses de mise en cache. Le CSS critique, le cache d'objets et les connexions persistantes repoussent la limite à partir de laquelle des goulots d'étranglement apparaissent. Les TTL courts pour les contenus fréquemment modifiés et les clés de cache différenciées pour la langue, le statut de l'utilisateur et le type d'appareil sont particulièrement utiles. Ainsi, le site reste rapide même s'il fournit des contenus personnalisés.
Sécurité et isolation : pools, contexte utilisateur, limites
Je préfère des hébergements multi-utilisateurs séparés. piscines par compte, afin que les droits, les chemins d'accès et les limites restent clairement séparés les uns des autres. mod_php partage un contexte commun, ce qui Risque augmente lorsqu'un projet présente des lacunes. FPM ou LSAPI avec des configurations par utilisateur réduisent considérablement cette surface d'attaque, car les processus s'exécutent sous l'utilisateur concerné. À cela s'ajoute la possibilité de définir différentes options php.ini au niveau du projet sans affecter les autres sites. Les limites de ressources telles que max_execution_time et memory_limit par pool empêchent les valeurs aberrantes de ralentir le serveur.
Consommation des ressources et planification de la RAM
Chaque worker PHP occupe, selon le code, les extensions et OPcache-taille variant considérablement, c'est pourquoi je mesure l'occupation réelle au lieu de la deviner. Des outils tels que ps, top ou systemd-cgtop indiquent la quantité de RAM réellement occupée par les travailleurs actifs et à quel moment. échange menace. Ensuite, je définis pm.max_children de manière conservatrice, je laisse une marge pour la base de données, le serveur web et les services de cache, puis j'observe la latence P95 sous le pic. S'il reste des réserves, j'augmente progressivement le nombre d'enfants et je vérifie à nouveau. Ainsi, la capacité totale augmente de manière contrôlée, sans surcharger le serveur.
Méthodologie de mesure : du TTFB au P99
Je n'évalue pas seulement les valeurs moyennes, mais surtout P95– et les latences P99, car elles reflètent l'expérience réelle sous charge. Une pile peut fonctionner avec un débit identique et néanmoins avoir un effet moins bon sur P99 si Files d'attente croître. C'est pourquoi je teste les caches froids et chauds, mélange les requêtes en lecture et en écriture et utilise des valeurs de concurrence réalistes. Sans préchauffage OPcache, j'interprète les résultats avec prudence, car de nombreux systèmes deviennent nettement plus rapides après quelques appels de préchauffage. Ce n'est qu'après des tests représentatifs que je décide du gestionnaire, de la stratégie de mise en cache et des limites du processus.
Guide décisionnel pour le choix du manutentionnaire
Pour les petits sites avec peu de connexions, mod_php ou un FPM-Configuration, dans la mesure où les aspects liés à la sécurité sont pris en compte. Si la simultanéité augmente, je passe à PHP-FPM avec des pools séparés pour chaque projet et j'active systématiquement OPcache. Pour les boutiques très dynamiques et comportant de nombreuses sessions, je préfère LiteSpeed avec LSAPI afin de maintenir les valeurs P95 et P99 à un niveau bas. Ceux qui restent sur Apache/Nginx pour des raisons de prix ou d'architecture obtiennent de très bons résultats avec un FPM correctement réglé. Dans tous les cas, les mesures effectuées dans des conditions réalistes sont plus importantes que les benchmarks sur un système vide.
Configuration pratique : mise en cache, sessions, délais
Je mise sur OPcache avec une généreuse Mémoire-Allocation, afin que le bytecode soit rarement remplacé, et déplacez les sessions vers Redis, pour éviter les verrous de fichiers. Cela réduit les temps d'attente lors de connexions simultanées et de pages personnalisées. Pour les services externes, je définis des délais d'attente et des disjoncteurs clairs afin que les pannes ne bloquent pas l'ensemble de la requête. Au niveau de l'application, je garde les TTL du cache suffisamment courts pour garantir l'actualité, mais suffisamment longs pour obtenir un taux de réussite élevé. Si vous atteignez régulièrement les limites des travailleurs, vous trouverez ici une introduction : Équilibrer correctement les workers PHP.
Comparaison coûts-avantages et exploitation
J'évalue les Coûts d'un changement contre un gain mesurable en termes de latence, de débit et de fiabilité. Le passage de FastCGI à PHP-FPM apporte souvent plus qu'un changement de numéro de version secondaire PHP, car Processus-Management et Caching agissent en continu. LSAPI est particulièrement intéressant lorsque LiteSpeed est déjà utilisé et que de nombreux visiteurs simultanés sont attendus. Si vous modifiez la pile, vous devez suivre de près les journaux et les métriques et préparer des chemins de retour en arrière. Une opération A/B planifiée sur plusieurs jours fournit les résultats les plus fiables.
Interaction entre serveurs web : Apache-MPM, Nginx et Keep-Alive
Dans la pratique, ce n'est pas seulement le gestionnaire PHP qui est déterminant, mais aussi le mode du serveur web. mod_php fonctionne avec Apache en mode prefork-MPM, mais bloque l'utilisation des modèles d'événements modernes. Si vous souhaitez utiliser efficacement HTTP/2, des phases Keep-Alive plus longues et des milliers de connexions, misez sur Apache. événement + PHP-FPM ou sur Nginx/LiteSpeed en tant que frontend. Conséquence : le nombre de PHP Workers nécessaires ne dépend pas du nombre de connexions TCP, mais du nombre réel de en même temps requêtes PHP en cours. Le multiplexage HTTP/2/3 réduit donc la surcharge des en-têtes sur le serveur web, mais ne change rien aux pools PHP sous-dimensionnés.
Nginx transfère généralement les requêtes à FPM via FastCGI. Je veille à ce que les read_timeout- et send_timeoutsur le proxy, sinon des erreurs 502/504 surviennent lors de suspensions en amont, même si PHP fonctionne toujours. Dans les environnements Apache, je limite Keep-Alive afin que les longues connexions inactives ne bloquent pas le pool de threads. LiteSpeed en abstrait une grande partie, mais ne tire pleinement parti de son avantage qu'avec LSAPI.
OPcache, JIT et préchargement : ce qui aide vraiment
OPcache est obligatoire. Dans la pratique, je dimensionne opcache.memory_consumption généreux (par exemple, 192 à 512 Mo selon la base de code) et augmente opcache.max_accelerated_files, afin d'éviter toute éviction. Pour les builds qui se déploient rarement, je désactive validate_timestamps ou définissez une valeur plus élevée revalidate_freq, pour économiser les appels système. Preloading peut accélérer les frameworks, mais est particulièrement efficace avec une structure d'autochargement cohérente. Le JIT de PHP apporte rarement des avantages pour les charges de travail Web classiques et peut même consommer de la RAM ; je ne l'active que lorsque des benchmarks en conditions réelles le confirment.
Gestion des files d'attente et contre-pression
La plupart des goulots d'étranglement ne se produisent pas dans le CPU, mais dans le file d'attente. Si le nombre de requêtes reçues dépasse la capacité de traitement des travailleurs, la file d'attente s'allonge et la latence P95/P99 augmente considérablement. Je m'assure que pm.max_children suffisamment grande pour absorber les pics typiques, mais suffisamment petite pour conserver une réserve de RAM. pm.max_requests Je le règle de manière modérée (par exemple entre 500 et 2000) afin que les fuites de mémoire ne génèrent pas de processus de longue durée. Le listen.backlog doit correspondre au backlog du serveur web, sinon le noyau interrompt les connexions sous charge. En mesurant le taux d'arrivée (requêtes par seconde) et le temps de service moyen, il est possible d'évaluer, à l'aide d'un simple calcul de capacité, à partir de quelle concurrence la latence bascule.
Délais d'attente, téléchargements et fichiers volumineux
Les téléchargements longs ou les appels API bloquent les travailleurs. Je définis des limites claires : max_execution_time et request_terminate_timeout dans FPM empêchent les requêtes défectueuses de s'exécuter indéfiniment. Au niveau du proxy, je synchronise proxy_read_timeout/fastcgi_read_timeout avec les limites FPM afin d'éviter les 504 prématurés. Je diffuse les téléchargements volumineux, je limite post_max_size et upload_max_filesize strict et planifie des points finaux dédiés afin que le reste du trafic n'en pâtisse pas. Pour les tâches de longue durée de type cron, je déplace le travail dans Queues de billard ou des tâches CLI, au lieu de bloquer les travailleurs front-end pendant plusieurs minutes.
Sessions et verrouillage en détail
Les sessions PHP sont par défaut bloquant. Une deuxième requête du même utilisateur attend que la première libère la session, ce qui est fatal pour WooCommerce lorsque des appels Ajax sont exécutés en parallèle. Je termine les accès en écriture de session prématurément avec session_write_close(), dès qu'aucune modification n'est plus nécessaire. Avec Redis comme backend de session, la latence d'E/S diminue, mais les règles de verrouillage restent importantes. Derrière les équilibreurs de charge, je choisis délibérément entre les sessions persistantes (simples, moins évolutives) et les modèles sans état avec cache d'objets, afin que l'évolutivité horizontale fonctionne correctement.
Monitoring et recherche d'erreurs
Sans télémétrie, le tuning est un vol à l'aveugle. J'active le statut FPM et les slowlogs par pool afin de voir les goulots d'étranglement et d'identifier les requêtes qui se démarquent.
; par pool pm.status_path = /status ping.path = /ping ping.response = pong request_slowlog_timeout = 3s slowlog = /var/log/php-fpm/www-slow.log pm.max_requests = 1000
Si des erreurs 502/504 surviennent, je vérifie d'abord : la file d'attente FPM est-elle pleine ? Y a-t-il un vol de CPU ou un swap ? Le délai d'expiration du serveur web correspond-il aux limites FPM ? Un coup d'œil dans smaps par travailleur indique l'occupation RSS réelle, tandis que netstat/ss Détecte les dépassements de backlog. Pour OPcache, je surveille le taux de réussite et le nombre de revalidations afin d'éviter les évictions.
Conteneurs, sockets et limites de ressources
Dans les conteneurs, j'utilise principalement TCP au lieu de sockets Unix entre le serveur web et FPM afin d'éviter les limites d'espace de noms et de faciliter l'équilibrage de charge. Il est important d'avoir des cgroupLimites : si le conteneur ne dispose que de 1 à 2 Go de RAM, pm.max_children doit être réduit en conséquence, sinon le OOM Killer intervient. Les quotas CPU ont une forte influence sur le temps de réponse ; je prévois une marge et vérifie la latence P95 sous la limite. Les questions NUMA et Core Affinity deviennent pertinentes en cas de charge très élevée, tandis que LSAPI optimise en grande partie cela en interne dans les configurations LiteSpeed.
Multi-versions PHP et extensions
De nombreux hébergeurs utilisent plusieurs versions PHP en parallèle. J'isole les pools par version et je conserve Extensions mince. Chaque module supplémentaire augmente la mémoire vive par travailleur et peut prolonger le temps de démarrage. Je supprime systématiquement les extensions inutilisées, ce qui apporte souvent plus qu'une petite augmentation de pm.max_children. Lors de la mise à niveau, je prévois de courtes phases de préchauffage pour OPcache afin que tous les utilisateurs ne subissent pas simultanément des démarrages à froid après le déploiement.
Régime RAM et planification réaliste des capacités
Au lieu d'utiliser des valeurs forfaitaires, je détermine la mémoire RAM moyenne et maximale requise par travailleur à partir du trafic en temps réel. J'en déduis que : (mémoire RAM disponible – système/base de données/caches) / mémoire RAM par travailleur = maximale pm.max_children raisonnable. De plus, je garde une réserve de 15 à 25 % pour les pics, le cache du noyau et les pics imprévus. Si l'application gonfle sporadiquement la mémoire, j'abaisse la limite ou je réduis pm.max_requests afin de recycler les processus plus fréquemment.
Stratégie de test : charge reproductible et modèles réels
J'utilise des profils de test qui mélangent des caches froids et chauds, combinent GET/POST et augmentent progressivement la concurrence. Important : ce n'est qu'avec OPcache actif et des temps de réflexion réalistes que je peux voir si le système reste stable en fonction du comportement d'utilisation. Une montée en puissance sur plusieurs minutes empêche les pics artificiels au démarrage. L'évaluation se concentre sur le TTFB et le P95/P99, et pas seulement sur le RTT moyen ou le req/s pur.
Exemples d'erreurs rencontrées dans la pratique
- Beaucoup de 504 sous le pic : file d'attente FPM pleine, backlog trop petit, délais d'attente au niveau du proxy plus courts que dans FPM.
- Bégaiement lors des déploiements : remplacements OPcache, absence de préchauffage, opcache.memory_consumption trop petit.
- Bonnes valeurs moyennes, mauvais P99 : trop de processus longs (E/S, API externes), absence de circuit breaking.
- CPU élevé, faible req/s : verrous de session ou requêtes de base de données non mises en cache qui limitent la série.
Sécurité opérationnelle et rollback
Je teste chaque modification apportée au gestionnaire ou aux paramètres du pool avec Drapeaux de fonctionnalités ou progressivement. Je surveille les journaux d'erreurs et de lenteur, le P95 et le taux d'erreur, et je définis une procédure de démantèlement claire en cas de basculement des métriques. Un deuxième pool avec une version identique, mais des paramètres différents, permet un changement A/B rapide sans temps d'arrêt. À pleine charge, une réduction automatique et brève de la concurrence (contre-pression) s'avère plus efficace que le démarrage incontrôlé de nouveaux travailleurs.
En bref
Pour les sites dynamiques avec de nombreux utilisateurs simultanés, je préfère LSAPI sur LiteSpeed, tandis que PHP-FPM sur Apache ou Nginx offre les meilleures Allrounder mod_php reste un cas particulier pour les projets très simples sans isolation stricte. Il est essentiel de réaliser des tests réalistes avec un OPcache chaud, des limites de pool raisonnables et une mise en cache propre. Pour réduire les latences de manière fiable, il faut mesurer P95/P99 et réagir en premier lieu aux problèmes de queue plutôt qu'aux valeurs moyennes. Une application obtient ainsi des réponses nettement plus rapides et dispose de plus de réserves pour les pics de trafic.
