Les listes de fonctionnalités au niveau de la surface racontent rarement l’histoire complète lorsque vous évaluez un hébergement WordPress infogéré pour le développement. Vous devez comprendre comment l’allocation des threads PHP affecte le traitement des requêtes simultanées, comment plusieurs couches de mise en cache fonctionnent ensemble pour réduire la charge de la base de données, et si la conteneurisation prévient réellement les problèmes dans des conditions réelles.
Ce guide présente l’architecture technique de Kinsta pour la gestion des threads PHP, la mise en cache multicouche et l’isolation des conteneurs. Nous incluons également des citations de Nikola Djuric, un ingénieur support senior de l’équipe Kinsta, sur les subtilités de la gestion des threads PHP.
Commençons par la façon dont PHP gère les requêtes.
Comprendre les threads PHP et pourquoi ils sont importants pour les performances de WordPress
Les threads PHP traitent les requêtes entrantes non mises en cache. Chaque thread traite une requête à la fois, donc votre nombre de threads disponibles affecte directement le nombre de visiteurs que votre site peut servir simultanément.
Lorsqu’un visiteur charge une page non mise en cache, soumet un formulaire ou ajoute un article à son panier :
- Le serveur web reçoit la requête et la transmet à PHP-FPM.
- PHP assigne la requête à un thread disponible.
- Ce thread exécute le code PHP, récupère les données de la base de données et génère une sortie dynamique.
- Une fois l’opération terminée, le thread redevient disponible.
La plupart des gens ne savent pas qu’une requête non mise en cache utilise un thread PHP et que la vitesse de traitement dépend du temps de réponse de PHP et de MySQL.
Les requêtes mises en cache sautent tout ce processus (elles ne touchent pas du tout à PHP), c’est pourquoi le taux de cache HIT est le facteur le plus important pour déterminer le nombre de threads dont vous avez réellement besoin.
Les sites WooCommerce, les tableaux de bord des membres, le trafic des API REST et les configurations sans tête contournent tous la mise en cache beaucoup plus souvent, ce qui signifie qu’ils consomment des threads rapidement.
Par exemple, si votre réponse API moyenne prend 250 millisecondes, chaque thread peut traiter quatre requêtes par seconde. Avec huit threads, votre débit maximal théorique est de 32 requêtes par seconde. Toutefois, cela n’est possible que si chaque requête est traitée en 250 ms exactement.
Comment le trafic concurrent consomme les threads PHP
Votre nombre de threads est le plus important en cas de trafic simultané. Si votre site dispose de quatre threads et reçoit six requêtes simultanées non mises en cache :
- Quatre requêtes commencent à être traitées immédiatement.
- Deux attendent un thread libre.
Si le nouveau trafic arrive plus vite que les threads ne peuvent se libérer, l’arriéré augmente.
La lenteur des requêtes de base de données aggrave la situation. Par exemple, une requête de base de données qui prend 10 secondes bloque un thread pendant toute cette durée. Si vous recevez trois requêtes simultanées qui déclenchent chacune des requêtes lentes, vous avez consommé trois threads pendant un total de 30 secondes. Pendant ce temps, les threads restants gèrent tout le reste du trafic.
Lorsque vous ajoutez des filtres WooCommerce, des pages de compte ou des flux de paiement, la pression des threads augmente encore.
Pour les threads PHP, les sites simples n’ont besoin que de quatre threads. Mais pour le commerce électronique, un nombre de threads inférieur à six est faible en raison du taux élevé de cache de contournement.
La relation entre le nombre de threads et le temps d’exécution
Une façon approximative d’estimer les besoins en threads :
Nombre de threads nécessaires ≈ (Requêtes non mises en cache par seconde × Temps d’exécution moyen)
Sur cette base, un site avec 10 requêtes non mises en cache par seconde et un temps d’exécution moyen de 0,5 seconde a besoin d’environ cinq threads pour gérer la charge sans file d’attente.
Cela explique pourquoi le simple fait d’ajouter des threads ne garantit pas de meilleures performances. Si la lenteur des requêtes de la base de données fait passer votre temps d’exécution moyen de 0,5 seconde à deux secondes, vos besoins en threads quadruplent.
La solution consiste à accélérer l’exécution du code. L’optimisation des requêtes, la réduction des appels aux API externes et la mise en place d’une mise en cache des objets peuvent réduire considérablement le temps d’exécution et le nombre de threads nécessaires pour gérer votre trafic.
Allocation de threads PHP à travers les plans Kinsta
Kinsta attribue des threads PHP en fonction des ressources CPU et RAM disponibles dans le conteneur de chaque site (chaque site Kinsta fonctionne dans son propre conteneur LXD, de sorte que les ressources sont isolées).
Schémas généraux pour les différents plans :
- Entrée de gamme : 2-4 threads à 256 Mo par thread. C’est la solution idéale pour les blogs et les sites à contenu statique avec des taux élevés d’accès au cache.
- Niveau intermédiaire : 6 à 8 threads à 256 Mo par thread, certains plans d’agence augmentant la mémoire à 512 Mo par thread.
- Niveau supérieur : 10 à 16 threads avec 512 Mo par thread, adapté aux sites complexes ou à fort trafic.
- Multisite : 8-14 threads selon le niveau.
Vous pouvez ajuster l’allocation des threads dans MyKinsta > Info > Performance PHP, en augmentant le pool de mémoire ou le nombre de threads en fonction du trafic de votre site.
Cette flexibilité vous permet d’adapter PHP à votre charge de travail réelle, plutôt que de vous fier aux valeurs par défaut.
Estimer les besoins en threads PHP pour votre site
Différents types de sites nécessitent des allocations de threads personnalisées en fonction de la quantité de trafic qui contourne le cache :
- Sites à contenu statique. 2 à 4 threads sont généralement suffisants car les pages mises en cache desservent la quasi-totalité du trafic.
- Boutiques WooCommerce. Commencez par 8 à 12 threads en fonction de la taille du catalogue, de la complexité du filtrage et du volume de commandes.
- Applications à forte intensité d’API ou headless. Estimez le nombre de threads en fonction du temps d’exécution (par exemple, des requêtes de 0,25 s = environ 4 par seconde par thread).
- Sites d’adhésion et plateformes LMS. Les utilisateurs connectés contournent entièrement la mise en cache, de sorte qu’ils se comportent de la même manière que les sites de commerce électronique.
L’analyse de MyKinsta vous aide à identifier les modèles d’utilisation des threads.
Si vous constatez des erreurs de mise en file d’attente ou de dépassement de temps lors de fenêtres à fort trafic, votre allocation de threads doit probablement être ajustée.
Que se passe-t-il lorsque vous dépassez votre limite de threads PHP ?
L’épuisement des threads suit un schéma prévisible :
Il n’y a pas de file d’attente pour les requêtes. Le nombre de threads PHP dont dispose votre site détermine le nombre de requêtes non mises en cache qui peuvent être traitées simultanément. Lorsqu’une requête arrive et qu’aucun thread n’est disponible, elle attend qu’un thread se libère. Si cela ne se produit pas assez rapidement, vous verrez apparaître des erreurs 502 ou 503 bad gateway timeout.
Symptômes typiques :
- Les requêtes sont mises en file d’attente dans NGINX/PHP-FPM lorsque tous les threads sont occupés à les traiter.
- Les utilisateurs finaux subissent d’abord des retards, tels que des chargeurs qui tournent, des étapes de paiement lentes ou des appels AJAX interrompus.
- Des erreurs 502 ou 504 apparaissent une fois que la file d’attente est complètement remplie.
- La récupération se produit généralement dans les 30 à 120 secondes qui suivent la fin des fonctions lentes et le réchauffement du cache.
Les requêtes de base de données lentes sont la cause la plus fréquente.
Les requêtes de base de données lentes prennent plus de temps à être traitées par les threads PHP et c’est ainsi qu’elles nuisent généralement aux performances du site.
Les appels d’API externes créent des problèmes similaires. Les passerelles de paiement, les services de calcul des taxes et les API d’expédition bloquent souvent les threads pendant le paiement.
Pour diagnostiquer l’épuisement des threads, il faut examiner plusieurs sources de données. L’outil APM de Kinsta trace les requêtes lentes et identifie les goulots d’étranglement, tandis que les journaux de requêtes lentes révèlent les problèmes de performance de la base de données. Les mesures de file d’attente de Nginx montrent les modèles d’arriérés de demandes et les ratios de cache HIT/MISS indiquent si votre mise en cache fonctionne.
La solution consiste à optimiser le temps d’exécution :
- Les requêtes de base de données lentes nécessitent une indexation, une optimisation des requêtes ou une réduction du nombre de requêtes.
- Les extensions lourdes peuvent nécessiter d’être remplacées par des solutions plus légères.
- Les tâches Cron doivent être déplacées vers les heures creuses.
- Les appels d’API externes bénéficient d’une mise en cache, d’un traitement en arrière-plan ou de coupe-circuits.
L’optimisation doit précéder l’ajout de threads. L’augmentation du nombre de threads n’est utile que lorsque le temps d’exécution moyen est maîtrisé.
L’architecture de mise en cache multicouche de Kinsta
La mise en cache réduit la fréquence à laquelle les requêtes atteignent PHP. Kinsta utilise trois couches :
- La mise en cache edge sert le contenu statique à partir d’emplacements globaux proches des visiteurs.
- La mise en cache d’objets avec Redis réduit la charge de la base de données en stockant les résultats des requêtes en mémoire.
- Le CDN de Kinsta fournit des ressources statiques à partir de sites distribués en périphérie.
Ces couches travaillent ensemble pour minimiser les requêtes qui atteignent vos threads PHP et votre base de données.
Mise en cache edge grâce à Cloudflare
Le réseau périphérique mondial de Cloudflare sert les pages HTML mises en cache sur la base de clés de cache qui prennent en compte :
- L’URL et les réglages de la requête
- Certains cookies
- L’état de l’authentification
- Les cookies de session et de panier de WooCommerce
Cela permet d’éviter qu’un contenu personnalisé soit proposé aux mauvais utilisateurs.
Les règles de contournement du cache empêchent également la mise en cache du contenu dynamique qui doit rester frais, comme les zones d’administration de WordPress ou les pages de paiement de WooCommerce.
La différence de performance signifie que les requêtes mises en cache edge contournent entièrement les threads PHP et n’atteignent jamais votre installation WordPress. Un site où 80 % des requêtes atteignent le cache edge n’a besoin de threads PHP que pour les 20 % restants du trafic.
Mise en cache d’objets avec Redis
Kinsta fournit Redis en tant que module plutôt que de nécessiter des extensions tierces, ce qui permet de s’assurer que Redis fonctionne avec le système de mise en cache d’objets de WordPress.
Redis stocke les résultats des requêtes de la base de données en mémoire, de sorte que le serveur n’a pas besoin de répéter l’exécution de ces requêtes.
Redis est un multiplicateur de performance pour les sites bien structurés, et non un pansement pour les requêtes lourdes ou les tables non indexées.
Redis est utile lorsque :
- De nombreux utilisateurs chargent les mêmes données (articles, produits, catégories)
- Les boutiques WooCommerce effectuent des recherches de catégories ou des vérifications de produits
- Les API répètent des requêtes identiques
Cependant, Redis n’accélère pas la logique PHP intrinsèquement lente, les appels API externes bloquants ou les boucles mal optimisées.
Kinsta CDN pour la fourniture de ressources globales
Le CDN de Kinsta sert des ressources statiques à partir de plus de 260 sites dans le monde. Cette approche réduit la latence pour les visiteurs internationaux et élimine les charges de ressources statiques de votre serveur d’origine. Il convertit également automatiquement les images au format WebP lorsque les navigateurs le prennent en charge.
Les en-têtes de contrôle du cache déterminent la durée de stockage des ressources par le CDN. Vous pouvez configurer la durée du cache pour différents types de ressources en fonction de leur fréquence de modification. Le noyau CSS, par exemple, peut supporter une période de cache prolongée. La purge du cache pour les deux couches est gérée par MyKinsta, soit individuellement, soit pour les deux.
Entre le CDN de Kinsta et la mise en cache edge, vous pouvez gérer les pages HTML, le contenu dynamique et les ressources statiques. Ensemble, ils garantissent que la plupart des requêtes n’atteignent jamais votre serveur d’origine ou ne consomment pas de threads PHP.
Isolation des conteneurs : résoudre le problème des voisins bruyants
Les environnements d’hébergement partagé souffrent souvent lorsqu’un site consomme trop de ressources. Kinsta évite ce problème grâce à l’isolation des conteneurs LXD, qui permet à chaque site d’avoir son propre conteneur :
- CPU dédié
- RAM dédiée
- Système de fichiers isolé
- Pile logicielle indépendante
D’autres sites ne peuvent pas « voler » vos ressources et les problèmes rencontrés dans un conteneur ne peuvent pas avoir d’incidence sur les autres.
Les conteneurs s’exécutent sur du matériel informatique optimisé, ce qui garantit des performances stables et prévisibles, même en cas de pics de trafic.
Évolution en fonction des besoins de votre site
Lorsque votre site a besoin de plus de ressources que ce que prévoit votre plan actuel, vous avez la possibilité d’évoluer verticalement au sein de votre conteneur.
Par exemple, le module de performance PHP fournit des threads et de la mémoire supplémentaires pour les sites qui ont besoin de plus de puissance de calcul.
Vous pouvez également passer à un plan de niveau supérieur, augmentant ainsi les ressources allouées à votre conteneur, le nombre de threads et la mémoire par thread. Cette option convient aux sites dont la capacité de leur plan actuel est insuffisante.
L’essentiel est de savoir si vous avez besoin d’une optimisation ou d’une capacité supplémentaire. Si vos threads saturent mais que l’utilisation du CPU reste faible, le problème vient des requêtes lentes ou des appels d’API externes, et non du nombre de threads. Si vous ajoutez des threads sans vous préoccuper des lenteurs d’exécution, vous ne ferez qu’allonger la durée d’attente des requêtes en attendant que les processus lents se terminent.
Résumé
La gestion des threads PHP, la mise en cache multicouche et l’isolation des conteneurs jouent tous un rôle critique dans les performances de WordPress à grande échelle. Comprendre comment les threads fonctionnent et comment la mise en cache réduit la charge qu’ils gèrent permet de choisir plus facilement le bon plan et d’optimiser votre site de manière efficace.
Si vous êtes prêt à voir comment l’infrastructure de Kinsta gère vos charges de travail WordPress, explorez la plateforme d’hébergement infogéré de Kinsta dès aujourd’hui.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
