Comprendre les threads PHP et pourquoi ils sont importants pour les performances de WordPress<\/h2>\n
Les threads PHP traitent les requ\u00eates entrantes non mises en cache. Chaque thread traite une requ\u00eate \u00e0 la fois<\/strong>, donc votre nombre de threads disponibles affecte directement le nombre de visiteurs que votre site peut servir simultan\u00e9ment.<\/p>\n Lorsqu’un visiteur charge une page non mise en cache, soumet un formulaire ou ajoute un article \u00e0 son panier :<\/p>\n La plupart des gens ne savent pas qu’une requ\u00eate non mise en cache utilise un thread PHP et que la vitesse de traitement d\u00e9pend du temps de r\u00e9ponse de PHP et de MySQL.<\/p><\/blockquote>\n Les requ\u00eates mises en cache sautent tout ce processus (elles ne touchent pas du tout \u00e0 PHP), c’est pourquoi le taux de cache Les sites WooCommerce, les tableaux de bord des membres, le trafic des API REST et les configurations sans t\u00eate contournent tous la mise en cache beaucoup plus souvent, ce qui signifie qu’ils consomment des threads rapidement.<\/p>\n Par exemple, si votre r\u00e9ponse API moyenne prend 250 millisecondes, chaque thread peut traiter quatre requ\u00eates par seconde. Avec huit threads, votre d\u00e9bit maximal th\u00e9orique est de 32 requ\u00eates par seconde. Toutefois, cela n’est possible que si chaque requ\u00eate est trait\u00e9e en 250 ms exactement.<\/p>\n Votre nombre de threads est le plus important en cas de trafic simultan\u00e9. Si votre site dispose de quatre threads et re\u00e7oit six requ\u00eates simultan\u00e9es non mises en cache :<\/p>\n Si le nouveau trafic arrive plus vite que les threads ne peuvent se lib\u00e9rer, l’arri\u00e9r\u00e9 augmente.<\/p>\n La lenteur des requ\u00eates de base de donn\u00e9es aggrave la situation. Par exemple, une requ\u00eate de base de donn\u00e9es qui prend 10 secondes bloque un thread pendant toute cette dur\u00e9e. Si vous recevez trois requ\u00eates simultan\u00e9es qui d\u00e9clenchent chacune des requ\u00eates lentes, vous avez consomm\u00e9 trois threads pendant un total de 30 secondes. Pendant ce temps, les threads restants g\u00e8rent tout le reste du trafic.<\/p>\n Lorsque vous ajoutez des filtres WooCommerce, des pages de compte ou des flux de paiement, la pression des threads augmente encore.<\/p>\n Pour les threads PHP, les sites simples n’ont besoin que de quatre threads. Mais pour le commerce \u00e9lectronique, un nombre de threads inf\u00e9rieur \u00e0 six est faible en raison du taux \u00e9lev\u00e9 de cache de contournement.<\/p><\/blockquote>\n Une fa\u00e7on approximative d’estimer les besoins en threads :<\/p>\n Nombre de threads n\u00e9cessaires \u2248 (Requ\u00eates non mises en cache par seconde \u00d7 Temps d’ex\u00e9cution moyen)<\/strong><\/p>\n Sur cette base, un site avec 10 requ\u00eates non mises en cache par seconde et un temps d’ex\u00e9cution moyen de 0,5 seconde a besoin d’environ cinq threads pour g\u00e9rer la charge sans file d’attente.<\/p>\n Cela explique pourquoi le simple fait d’ajouter des threads ne garantit pas de meilleures performances. Si la lenteur des requ\u00eates de la base de donn\u00e9es fait passer votre temps d’ex\u00e9cution moyen de 0,5 seconde \u00e0 deux secondes, vos besoins en threads quadruplent.<\/p>\n La solution consiste \u00e0 acc\u00e9l\u00e9rer l’ex\u00e9cution du code. L’optimisation des requ\u00eates<\/a>, la r\u00e9duction des appels aux API externes et la mise en place d’une mise en cache des objets peuvent r\u00e9duire consid\u00e9rablement le temps d’ex\u00e9cution et le nombre de threads n\u00e9cessaires pour g\u00e9rer votre trafic.<\/p>\n 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<\/a>, de sorte que les ressources sont isol\u00e9es).<\/p>\n Sch\u00e9mas g\u00e9n\u00e9raux pour les diff\u00e9rents plans :<\/p>\n Vous pouvez ajuster l’allocation des threads dans MyKinsta<\/strong><\/a> > Info<\/strong> > Performance PHP<\/strong>, en augmentant le pool de m\u00e9moire ou le nombre de threads en fonction du trafic de votre site.<\/p>\n Cette flexibilit\u00e9 vous permet d’adapter PHP \u00e0 votre charge de travail r\u00e9elle, plut\u00f4t que de vous fier aux valeurs par d\u00e9faut.<\/p>\n Diff\u00e9rents types de sites n\u00e9cessitent des allocations de threads personnalis\u00e9es en fonction de la quantit\u00e9 de trafic qui contourne le cache :<\/p>\n L’analyse de MyKinsta<\/a> vous aide \u00e0 identifier les mod\u00e8les d’utilisation des threads.<\/p>\n Si vous constatez des erreurs de mise en file d’attente ou de d\u00e9passement de temps lors de fen\u00eatres \u00e0 fort trafic, votre allocation de threads doit probablement \u00eatre ajust\u00e9e.<\/p>\n L’\u00e9puisement des threads suit un sch\u00e9ma pr\u00e9visible :<\/p>\n Il n’y a pas de file d’attente pour les requ\u00eates. Le nombre de threads PHP dont dispose votre site d\u00e9termine le nombre de requ\u00eates non mises en cache qui peuvent \u00eatre trait\u00e9es simultan\u00e9ment. Lorsqu’une requ\u00eate arrive et qu’aucun thread n’est disponible, elle attend qu’un thread se lib\u00e8re. Si cela ne se produit pas assez rapidement, vous verrez appara\u00eetre des erreurs 502 ou 503 bad gateway timeout.<\/p><\/blockquote>\n Sympt\u00f4mes typiques :<\/p>\n Les requ\u00eates de base de donn\u00e9es lentes sont la cause la plus fr\u00e9quente.<\/p>\n Les requ\u00eates de base de donn\u00e9es lentes prennent plus de temps \u00e0 \u00eatre trait\u00e9es par les threads PHP et c’est ainsi qu’elles nuisent g\u00e9n\u00e9ralement aux performances du site.<\/p><\/blockquote>\n Les appels d’API externes cr\u00e9ent des probl\u00e8mes similaires. Les passerelles de paiement, les services de calcul des taxes et les API d’exp\u00e9dition bloquent souvent les threads pendant le paiement.<\/p>\n Pour diagnostiquer l’\u00e9puisement des threads, il faut examiner plusieurs sources de donn\u00e9es. L’outil APM de Kinsta<\/a> trace les requ\u00eates lentes et identifie les goulots d’\u00e9tranglement, tandis que les journaux de requ\u00eates lentes r\u00e9v\u00e8lent les probl\u00e8mes de performance de la base de donn\u00e9es. Les mesures de file d’attente de Nginx montrent les mod\u00e8les d’arri\u00e9r\u00e9s de demandes et les ratios de cache La solution consiste \u00e0 optimiser le temps d’ex\u00e9cution :<\/p>\n L’optimisation doit pr\u00e9c\u00e9der l’ajout de threads. L’augmentation du nombre de threads n’est utile que lorsque<\/em> le temps d’ex\u00e9cution moyen est ma\u00eetris\u00e9.<\/p>\n La mise en cache r\u00e9duit la fr\u00e9quence \u00e0 laquelle les requ\u00eates atteignent PHP. Kinsta utilise trois couches :<\/p>\n Ces couches travaillent ensemble pour minimiser les requ\u00eates qui atteignent vos threads PHP et votre base de donn\u00e9es.<\/p>\n Le r\u00e9seau p\u00e9riph\u00e9rique mondial de Cloudflare sert les pages HTML mises en cache sur la base de cl\u00e9s de cache qui prennent en compte :<\/p>\n Cela permet d’\u00e9viter qu’un contenu personnalis\u00e9 soit propos\u00e9 aux mauvais utilisateurs.<\/p>\n Les r\u00e8gles de contournement du cache emp\u00eachent \u00e9galement 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.<\/p>\n La diff\u00e9rence de performance signifie que les requ\u00eates mises en cache edge contournent enti\u00e8rement les threads PHP et n’atteignent jamais votre installation WordPress. Un site o\u00f9 80 % des requ\u00eates atteignent le cache edge n’a besoin de threads PHP que pour les 20 % restants du trafic.<\/p>\n Kinsta fournit Redis en tant que module<\/a> plut\u00f4t que de n\u00e9cessiter des extensions tierces, ce qui permet de s’assurer que Redis fonctionne avec le syst\u00e8me de mise en cache d’objets de WordPress.<\/p>\n Redis stocke les r\u00e9sultats des requ\u00eates de la base de donn\u00e9es en m\u00e9moire, de sorte que le serveur n’a pas besoin de r\u00e9p\u00e9ter l’ex\u00e9cution de ces requ\u00eates.<\/p>\n Redis est un multiplicateur de performance pour les sites bien structur\u00e9s, et non un pansement pour les requ\u00eates lourdes ou les tables non index\u00e9es.<\/p><\/blockquote>\n Redis est utile lorsque :<\/p>\n Cependant, Redis n’acc\u00e9l\u00e8re pas la logique PHP intrins\u00e8quement lente, les appels API externes bloquants ou les boucles mal optimis\u00e9es.<\/p>\n Le CDN de Kinsta<\/a> sert des ressources statiques \u00e0 partir de plus de 260 sites dans le monde. Cette approche r\u00e9duit la latence pour les visiteurs internationaux et \u00e9limine les charges de ressources statiques de votre serveur d’origine. Il convertit \u00e9galement automatiquement les images au format WebP lorsque les navigateurs le prennent en charge.<\/p>\n Les en-t\u00eates de contr\u00f4le du cache d\u00e9terminent la dur\u00e9e de stockage des ressources par le CDN. Vous pouvez configurer la dur\u00e9e du cache pour diff\u00e9rents types de ressources en fonction de leur fr\u00e9quence de modification. Le noyau CSS, par exemple, peut supporter une p\u00e9riode de cache prolong\u00e9e. La purge du cache pour les deux couches est g\u00e9r\u00e9e par MyKinsta, soit individuellement, soit pour les deux.<\/p>\n Entre le CDN de Kinsta et la mise en cache edge, vous pouvez g\u00e9rer les pages HTML, le contenu dynamique et les ressources statiques. Ensemble, ils garantissent que la plupart des requ\u00eates n’atteignent jamais votre serveur d’origine ou ne consomment pas de threads PHP.<\/p>\n Les environnements d’h\u00e9bergement partag\u00e9<\/a> souffrent souvent lorsqu’un site consomme trop de ressources. Kinsta \u00e9vite ce probl\u00e8me gr\u00e2ce \u00e0 l’isolation des conteneurs LXD<\/strong>, qui permet \u00e0 chaque site d’avoir son propre conteneur :<\/p>\n D’autres sites ne peuvent pas \u00ab voler \u00bb vos ressources et les probl\u00e8mes rencontr\u00e9s dans un conteneur ne peuvent pas avoir d’incidence sur les autres.<\/p>\n Les conteneurs s’ex\u00e9cutent sur du mat\u00e9riel informatique optimis\u00e9, ce qui garantit des performances stables et pr\u00e9visibles, m\u00eame en cas de pics de trafic.<\/p>\n Lorsque votre site a besoin de plus de ressources que ce que pr\u00e9voit votre plan actuel, vous avez la possibilit\u00e9 d’\u00e9voluer verticalement au sein de votre conteneur.<\/p>\n\n
HIT<\/code> est le facteur le plus important pour d\u00e9terminer le nombre de threads dont vous avez r\u00e9ellement besoin.<\/p>\nComment le trafic concurrent consomme les threads PHP<\/h3>\n
\n
La relation entre le nombre de threads et le temps d’ex\u00e9cution<\/h3>\n
Allocation de threads PHP \u00e0 travers les plans Kinsta<\/h2>\n
\n
![\"Ajuster](\"https:\/\/kinsta.com\/wp-content\/uploads\/2025\/12\/php-performance-screen.png\")
Estimer les besoins en threads PHP pour votre site<\/h2>\n
\n
![\"Les](\"https:\/\/kinsta.com\/wp-content\/uploads\/2025\/12\/php-threads-table.png\")
Que se passe-t-il lorsque vous d\u00e9passez votre limite de threads PHP ?<\/h2>\n
\n
HIT<\/code>\/MISS<\/code> indiquent si votre mise en cache fonctionne.<\/p>\n\n
L’architecture de mise en cache multicouche de Kinsta<\/h2>\n
\n
Mise en cache edge gr\u00e2ce \u00e0 Cloudflare<\/h3>\n
\n
Mise en cache d’objets avec Redis<\/h3>\n
\n
Kinsta CDN pour la fourniture de ressources globales<\/h3>\n
Isolation des conteneurs : r\u00e9soudre le probl\u00e8me des voisins bruyants<\/h2>\n
\n
\u00c9volution en fonction des besoins de votre site<\/h3>\n