Entendendo threads PHP e por que elas s\u00e3o importantes para o desempenho do WordPress<\/h2>\n
As threads PHP processam solicita\u00e7\u00f5es n\u00e3o armazenadas em cache. Cada thread lida com uma solicita\u00e7\u00e3o por vez<\/strong>, portanto, a quantidade de threads dispon\u00edveis afeta diretamente quantos visitantes seu site consegue atender simultaneamente.<\/p>\n Quando um visitante carrega uma p\u00e1gina n\u00e3o armazenada em cache, envia formul\u00e1rios ou adiciona um item ao carrinho:<\/p>\n A maioria das pessoas n\u00e3o sabe que uma solicita\u00e7\u00e3o n\u00e3o armazenada em cache consome uma thread PHP e que a velocidade de processamento depende do PHP somado ao tempo de resposta do MySQL.<\/p><\/blockquote>\n Solicita\u00e7\u00f5es armazenadas em cache pulam todo esse processo, n\u00e3o passam pelo PHP, o que explica por que as taxas de cache Sites WooCommerce, pain\u00e9is de membros, tr\u00e1fego de API REST e configura\u00e7\u00f5es headless ignoram o cache com muito mais frequ\u00eancia, o que significa que consomem threads rapidamente.<\/p>\n Por exemplo, se a resposta m\u00e9dia de uma API leva 250 milissegundos, cada thread consegue processar quatro solicita\u00e7\u00f5es por segundo. Com oito threads, o throughput te\u00f3rico m\u00e1ximo \u00e9 de 32 solicita\u00e7\u00f5es por segundo. No entanto, isso s\u00f3 \u00e9 v\u00e1lido se todas as solicita\u00e7\u00f5es forem conclu\u00eddas exatamente em 250 ms.<\/p>\n A quantidade de threads \u00e9 mais cr\u00edtica durante tr\u00e1fego simult\u00e2neo. Se seu site possui quatro threads e recebe seis solicita\u00e7\u00f5es n\u00e3o armazenadas em cache ao mesmo tempo:<\/p>\n Se novas solicita\u00e7\u00f5es chegam mais r\u00e1pido do que as threads s\u00e3o liberadas, o ac\u00famulo cresce.<\/p>\n Consultas lentas ao banco de dados pioram esse cen\u00e1rio. Por exemplo, uma consulta que leva 10 segundos mant\u00e9m uma thread ocupada por todo esse tempo. Se voc\u00ea receber tr\u00eas solicita\u00e7\u00f5es simult\u00e2neas que acionam consultas lentas, tr\u00eas threads ficam ocupadas por um total de 30 segundos. Durante esse per\u00edodo, as threads restantes lidam com todo o restante do tr\u00e1fego.<\/p>\n Quando voc\u00ea adiciona filtros do WooCommerce, p\u00e1ginas de conta ou fluxos de checkout, a press\u00e3o sobre as threads aumenta ainda mais.<\/p>\n Para sites simples, quatro threads geralmente s\u00e3o suficientes. J\u00e1 para eCommerce, qualquer valor abaixo de seis \u00e9 baixo devido \u00e0 alta taxa de bypass de cache.<\/p><\/blockquote>\n Uma forma aproximada de estimar a necessidade de threads \u00e9:<\/p>\n Threads necess\u00e1rias \u2248 (solicita\u00e7\u00f5es n\u00e3o armazenadas em cache por segundo \u00d7 tempo m\u00e9dio de execu\u00e7\u00e3o)<\/strong><\/p>\n Com base nisso, um site com 10 solicita\u00e7\u00f5es n\u00e3o armazenadas em cache por segundo e tempo m\u00e9dio de execu\u00e7\u00e3o de 0,5 segundo precisa de aproximadamente cinco threads para lidar com a carga sem filas.<\/p>\n Isso explica por que simplesmente adicionar mais threads n\u00e3o garante melhor desempenho. Se consultas lentas ao banco de dados fizerem o tempo m\u00e9dio de execu\u00e7\u00e3o aumentar de 0,5 para dois segundos, a necessidade de threads quadruplica.<\/p>\n A solu\u00e7\u00e3o \u00e9 uma execu\u00e7\u00e3o mais r\u00e1pida do c\u00f3digo. A otimiza\u00e7\u00e3o das consultas<\/a>, a redu\u00e7\u00e3o das chamadas de API externas e a implementa\u00e7\u00e3o do cache de objetos adequado podem reduzir drasticamente o tempo de execu\u00e7\u00e3o e os threads necess\u00e1rios para lidar com o tr\u00e1fego.<\/p>\n A Kinsta atribui threads PHP com base nos recursos de CPU e RAM dispon\u00edveis para o cont\u00eainer de cada site (cada site da Kinsta \u00e9 executado em seu pr\u00f3prio cont\u00eainer LXD<\/a>, portanto, os recursos s\u00e3o isolados).<\/p>\n Padr\u00f5es gerais entre os planos:<\/p>\n Voc\u00ea pode ajustar a aloca\u00e7\u00e3o de threads dentro do MyKinsta<\/strong><\/a> > Informa\u00e7\u00f5es<\/strong> > Desempenho PHP<\/strong>, aumentando o pool de mem\u00f3ria ou a contagem de threads com base nos padr\u00f5es de tr\u00e1fego do seu site.<\/p>\n Essa flexibilidade permite ajustar o PHP \u00e0 carga real do site, em vez de depender de configura\u00e7\u00f5es padr\u00e3o.<\/p>\n Diferentes tipos de sites precisam de aloca\u00e7\u00f5es personalizadas de threads com base na quantidade de tr\u00e1fego que ignora o cache:<\/p>\n As an\u00e1lises dispon\u00edveis no MyKinsta<\/a> ajudam a identificar os padr\u00f5es atuais de uso de threads.<\/p>\n Se voc\u00ea observar filas de solicita\u00e7\u00f5es ou erros de timeout durante picos de tr\u00e1fego, \u00e9 prov\u00e1vel que a aloca\u00e7\u00e3o de threads precise de ajustes.<\/p>\n A exaust\u00e3o de thread segue um padr\u00e3o previs\u00edvel:<\/p>\n N\u00e3o h\u00e1 fila para solicita\u00e7\u00f5es. O n\u00famero de threads PHP que seu site tem determina quantas solicita\u00e7\u00f5es n\u00e3o armazenadas em cache podem ser processadas de uma vez. Quando uma solicita\u00e7\u00e3o chega e nenhum thread est\u00e1 dispon\u00edvel, ela espera que um thread seja liberado. Se isso n\u00e3o acontecer r\u00e1pido o suficiente, surgem erros 502 ou 503 de bad gateway por timeout.<\/p><\/blockquote>\n Sintomas t\u00edpicos:<\/p>\n As consultas lentas ao banco de dados s\u00e3o a causa mais comum.<\/p>\n Consultas lentas levam mais tempo para serem processadas pelas threads PHP, e \u00e9 assim que normalmente comprometem o desempenho de um site.<\/p><\/blockquote>\n Chamadas a APIs externas criam problemas semelhantes. Gateways de pagamento, servi\u00e7os de c\u00e1lculo de impostos e APIs de frete frequentemente bloqueiam threads durante o checkout.<\/p>\n Para diagnosticar a exaust\u00e3o de threads, voc\u00ea precisa examinar v\u00e1rias fontes de dados. A ferramenta de APM da Kinsta<\/a> rastreia solicita\u00e7\u00f5es lentas e identifica gargalos, enquanto os registros de consultas lentas revelam problemas de desempenho do banco de dados. As m\u00e9tricas de fila do Nginx mostram padr\u00f5es de atraso de solicita\u00e7\u00f5es e as taxas de cache A solu\u00e7\u00e3o \u00e9 otimizar o tempo de execu\u00e7\u00e3o:<\/p>\n A otimiza\u00e7\u00e3o deve vir antes de adicionar mais threads. Aumentar a quantidade de threads s\u00f3 ajuda depois que o tempo m\u00e9dio de execu\u00e7\u00e3o est\u00e1 sob controle.<\/p>\n O armazenamento em cache reduz a frequ\u00eancia com que as solicita\u00e7\u00f5es chegam ao PHP. A Kinsta usa tr\u00eas camadas:<\/p>\n Essas camadas trabalham em conjunto para minimizar as solicita\u00e7\u00f5es que chegam \u00e0s threads PHP e ao banco de dados.<\/p>\n A rede global de borda do Cloudflare entrega p\u00e1ginas HTML armazenadas em cache com base em chaves de cache que consideram:<\/p>\n Isso evita que o conte\u00fado personalizado seja fornecido aos usu\u00e1rios errados.<\/p>\n Regras de bypass de cache tamb\u00e9m impedem o armazenamento em cache de conte\u00fado din\u00e2mico que precisa permanecer atualizado, como \u00e1reas administrativas do WordPress ou p\u00e1ginas de checkout do WooCommerce.<\/p>\n A diferen\u00e7a de desempenho \u00e9 significativa, solicita\u00e7\u00f5es atendidas pelo Edge Caching ignoram completamente as threads PHP e nunca chegam \u00e0 instala\u00e7\u00e3o do WordPress. Um site em que 80% das solicita\u00e7\u00f5es s\u00e3o atendidas pelo Edge Caching precisa de threads PHP apenas para os 20% restantes do tr\u00e1fego.<\/p>\n A Kinsta fornece o Redis como um complemento<\/a> em vez de exigir plugins de terceiros, o que pode garantir que o Redis funcione com o sistema de cache de objetos do WordPress.<\/p>\n O Redis armazena os resultados das consultas ao banco de dados na mem\u00f3ria, de modo que o servidor n\u00e3o precisa repetir a execu\u00e7\u00e3o dessas consultas.<\/p>\n O Redis \u00e9 um multiplicador de desempenho para sites bem estruturados, e n\u00e3o uma solu\u00e7\u00e3o para consultas pesadas ou tabelas n\u00e3o indexadas.<\/p><\/blockquote>\n O Redis ajuda quando:<\/p>\n No entanto, o Redis n\u00e3o acelera a l\u00f3gica PHP inerentemente lenta, bloqueando chamadas de API externas ou loops mal otimizados.<\/p>\n O CDN da Kinsta<\/a> fornece ativos est\u00e1ticos de mais de 260 localiza\u00e7\u00f5es globais. Essa abordagem reduz a lat\u00eancia para visitantes internacionais e elimina o carregamento de ativos est\u00e1ticos do seu servidor de origem. Ela tamb\u00e9m converte automaticamente as imagens para o formato WebP quando os navegadores o suportam.<\/p>\n Cabe\u00e7alhos de controle de cache determinam por quanto tempo os ativos permanecem armazenados no CDN. \u00c9 poss\u00edvel configurar a dura\u00e7\u00e3o do cache para diferentes tipos de ativos com base na frequ\u00eancia de altera\u00e7\u00f5es. Arquivos CSS principais, por exemplo, podem utilizar per\u00edodos de cache mais longos. A limpeza do cache, tanto do CDN quanto do Edge Caching, \u00e9 feita pelo MyKinsta, de forma individual ou conjunta.<\/p>\n Entre o CDN da Kinsta e o cache do Edge, voc\u00ea pode lidar com p\u00e1ginas HTML, conte\u00fado din\u00e2mico e ativos est\u00e1ticos. Juntos, eles garantem que a maioria das solicita\u00e7\u00f5es nunca chegue ao seu servidor de origem ou consuma threads PHP.<\/p>\n Os ambientes de hospedagem compartilhada<\/a> geralmente sofrem quando um site consome muitos recursos. A Kinsta evita esse problema por completo por meio do isolamento com cont\u00eaineres LXD<\/strong>, fornecendo a cada site:<\/p>\n Outros sites n\u00e3o podem \u201croubar\u201d seus recursos, e problemas em um cont\u00eainer n\u00e3o afetam os demais.<\/p>\n Os cont\u00eaineres s\u00e3o executados em hardware de computa\u00e7\u00e3o otimizado, garantindo desempenho est\u00e1vel e previs\u00edvel, mesmo durante picos de tr\u00e1fego.<\/p>\n Quando seu site passa a exigir consistentemente mais recursos do que o plano atual oferece, existem op\u00e7\u00f5es para escalar verticalmente dentro do pr\u00f3prio cont\u00eainer.<\/p>\n\n
HIT<\/code> s\u00e3o o fator mais importante para determinar quantas threads voc\u00ea realmente precisa.<\/p>\nComo o tr\u00e1fego simult\u00e2neo consome threads PHP<\/h3>\n
\n
A rela\u00e7\u00e3o entre n\u00famero de threads e tempo de execu\u00e7\u00e3o<\/h3>\n
Aloca\u00e7\u00e3o de threads PHP nos planos da Kinsta<\/h2>\n
\n
![\"A](\"https:\/\/kinsta.com\/wp-content\/uploads\/2025\/12\/php-performance-screen.png\")
Estimando a necessidade de threads PHP para o seu site<\/h2>\n
\n
![\"An\u00e1lises](\"https:\/\/kinsta.com\/wp-content\/uploads\/2025\/12\/php-threads-table.png\")
O que acontece quando voc\u00ea excede o limite de threads PHP<\/h2>\n
\n
HIT<\/code>\/MISS<\/code> indicam se o cache est\u00e1 funcionando.<\/p>\n\n
Arquitetura de cache em m\u00faltiplas camadas da Kinsta<\/h2>\n
\n
Edge Caching por meio do Cloudflare<\/h3>\n
\n
Cache de objetos com o Redis<\/h3>\n
\n
Kinsta CDN para entrega global de ativos<\/h3>\n
Isolamento de cont\u00eaineres: resolvendo o problema do \u201cvizinho barulhento\u201d<\/h2>\n
\n
Escalando de acordo com as necessidades do seu site<\/h3>\n