As listas de recursos de nível superficial raramente revelam a história completa quando você avalia a hospedagem gerenciada para WordPress voltada ao desenvolvimento. É necessário entender como a alocação de threads PHP impacta o processamento de solicitações simultâneas, como múltiplas camadas de cache trabalham juntas para reduzir a carga no banco de dados e se o isolamento por contêiner realmente previne problemas em condições reais.
Este guia detalha a arquitetura técnica da Kinsta para gerenciamento de threads PHP, cache em múltiplas camadas e isolamento por contêiner. Também incluímos citações de Nikola Djuric, engenheiro sênior de suporte da equipe da Kinsta, sobre as complexidades do gerenciamento de threads PHP.
Vamos começar entendendo como o PHP realmente lida com solicitações.
Entendendo threads PHP e por que elas são importantes para o desempenho do WordPress
As threads PHP processam solicitações não armazenadas em cache. Cada thread lida com uma solicitação por vez, portanto, a quantidade de threads disponíveis afeta diretamente quantos visitantes seu site consegue atender simultaneamente.
Quando um visitante carrega uma página não armazenada em cache, envia formulários ou adiciona um item ao carrinho:
- O servidor web recebe a solicitação e a encaminha ao PHP-FPM.
- O PHP atribui a solicitação a uma thread disponível.
- Essa thread executa o código PHP, busca dados no banco de dados e gera a saída dinâmica.
- Após a conclusão, a thread fica disponível novamente.
A maioria das pessoas não sabe que uma solicitação não armazenada em cache consome uma thread PHP e que a velocidade de processamento depende do PHP somado ao tempo de resposta do MySQL.
Solicitações armazenadas em cache pulam todo esse processo, não passam pelo PHP, o que explica por que as taxas de cache HIT são o fator mais importante para determinar quantas threads você realmente precisa.
Sites WooCommerce, painéis de membros, tráfego de API REST e configurações headless ignoram o cache com muito mais frequência, o que significa que consomem threads rapidamente.
Por exemplo, se a resposta média de uma API leva 250 milissegundos, cada thread consegue processar quatro solicitações por segundo. Com oito threads, o throughput teórico máximo é de 32 solicitações por segundo. No entanto, isso só é válido se todas as solicitações forem concluídas exatamente em 250 ms.
Como o tráfego simultâneo consome threads PHP
A quantidade de threads é mais crítica durante tráfego simultâneo. Se seu site possui quatro threads e recebe seis solicitações não armazenadas em cache ao mesmo tempo:
- Quatro solicitações começam a ser processadas imediatamente.
- Duas aguardam uma thread livre.
Se novas solicitações chegam mais rápido do que as threads são liberadas, o acúmulo cresce.
Consultas lentas ao banco de dados pioram esse cenário. Por exemplo, uma consulta que leva 10 segundos mantém uma thread ocupada por todo esse tempo. Se você receber três solicitações simultâneas que acionam consultas lentas, três threads ficam ocupadas por um total de 30 segundos. Durante esse período, as threads restantes lidam com todo o restante do tráfego.
Quando você adiciona filtros do WooCommerce, páginas de conta ou fluxos de checkout, a pressão sobre as threads aumenta ainda mais.
Para sites simples, quatro threads geralmente são suficientes. Já para eCommerce, qualquer valor abaixo de seis é baixo devido à alta taxa de bypass de cache.
A relação entre número de threads e tempo de execução
Uma forma aproximada de estimar a necessidade de threads é:
Threads necessárias ≈ (solicitações não armazenadas em cache por segundo × tempo médio de execução)
Com base nisso, um site com 10 solicitações não armazenadas em cache por segundo e tempo médio de execução de 0,5 segundo precisa de aproximadamente cinco threads para lidar com a carga sem filas.
Isso explica por que simplesmente adicionar mais threads não garante melhor desempenho. Se consultas lentas ao banco de dados fizerem o tempo médio de execução aumentar de 0,5 para dois segundos, a necessidade de threads quadruplica.
A solução é uma execução mais rápida do código. A otimização das consultas, a redução das chamadas de API externas e a implementação do cache de objetos adequado podem reduzir drasticamente o tempo de execução e os threads necessários para lidar com o tráfego.
Alocação de threads PHP nos planos da Kinsta
A Kinsta atribui threads PHP com base nos recursos de CPU e RAM disponíveis para o contêiner de cada site (cada site da Kinsta é executado em seu próprio contêiner LXD, portanto, os recursos são isolados).
Padrões gerais entre os planos:
- Planos de entrada: 2 a 4 threads com 256 MB por thread. Ideal para blogs e sites de conteúdo estático com altas taxas de cache HIT.
- Planos intermediários: 6 a 8 threads com 256 MB por thread, com alguns planos para agências aumentando a memória para 512 MB por thread.
- Planos superiores: 10 a 16 threads com 512 MB por thread, adequados para sites complexos ou com alto tráfego.
- Multisite: 8 a 14 threads, dependendo do plano.
Você pode ajustar a alocação de threads dentro do MyKinsta > Informações > Desempenho PHP, aumentando o pool de memória ou a contagem de threads com base nos padrões de tráfego do seu site.
Essa flexibilidade permite ajustar o PHP à carga real do site, em vez de depender de configurações padrão.
Estimando a necessidade de threads PHP para o seu site
Diferentes tipos de sites precisam de alocações personalizadas de threads com base na quantidade de tráfego que ignora o cache:
- Sites de conteúdo estático: 2 a 4 threads geralmente são suficientes, pois quase todo o tráfego é atendido pelo cache.
- Lojas WooCommerce: comece com 8 a 12 threads, dependendo do tamanho do catálogo, da complexidade dos filtros e do volume de checkouts.
- Aplicativos com uso intenso de API ou headless: estime com base no tempo de execução, por exemplo, solicitações de 0,25 s equivalem a cerca de quatro por segundo por thread.
- Sites de membros e plataformas LMS: usuários logados ignoram completamente o cache, portanto se comportam de forma semelhante ao eCommerce.
As análises disponíveis no MyKinsta ajudam a identificar os padrões atuais de uso de threads.
Se você observar filas de solicitações ou erros de timeout durante picos de tráfego, é provável que a alocação de threads precise de ajustes.
O que acontece quando você excede o limite de threads PHP
A exaustão de thread segue um padrão previsível:
Não há fila para solicitações. O número de threads PHP que seu site tem determina quantas solicitações não armazenadas em cache podem ser processadas de uma vez. Quando uma solicitação chega e nenhum thread está disponível, ela espera que um thread seja liberado. Se isso não acontecer rápido o suficiente, surgem erros 502 ou 503 de bad gateway por timeout.
Sintomas típicos:
- As solicitações entram em fila dentro do NGINX ou PHP-FPM enquanto todas as threads estão ocupadas.
- Os usuários finais percebem atrasos primeiro, como carregamentos giratórios, etapas lentas no checkout ou chamadas AJAX quebradas.
- Erros 502 ou 504 aparecem quando a capacidade da fila se esgota completamente.
- A recuperação ocorre normalmente entre 30 e 120 segundos após funções lentas finalizarem e o cache ser aquecido novamente.
As consultas lentas ao banco de dados são a causa mais comum.
Consultas lentas levam mais tempo para serem processadas pelas threads PHP, e é assim que normalmente comprometem o desempenho de um site.
Chamadas a APIs externas criam problemas semelhantes. Gateways de pagamento, serviços de cálculo de impostos e APIs de frete frequentemente bloqueiam threads durante o checkout.
Para diagnosticar a exaustão de threads, você precisa examinar várias fontes de dados. A ferramenta de APM da Kinsta rastreia solicitações lentas e identifica gargalos, enquanto os registros de consultas lentas revelam problemas de desempenho do banco de dados. As métricas de fila do Nginx mostram padrões de atraso de solicitações e as taxas de cache HIT/MISS indicam se o cache está funcionando.
A solução é otimizar o tempo de execução:
- Consultas lentas precisam de indexação, otimização ou redução no número de chamadas.
- Plugins pesados podem precisar ser substituídos por alternativas mais leves.
- Tarefas de cron devem ser movidas para horários de menor tráfego.
- Chamadas a APIs externas se beneficiam de cache, processamento em segundo plano ou circuit breakers.
A otimização deve vir antes de adicionar mais threads. Aumentar a quantidade de threads só ajuda depois que o tempo médio de execução está sob controle.
Arquitetura de cache em múltiplas camadas da Kinsta
O armazenamento em cache reduz a frequência com que as solicitações chegam ao PHP. A Kinsta usa três camadas:
- Edge Caching entrega conteúdo estático a partir de localizações globais próximas aos visitantes.
- Cache de objetos com Redis reduz a carga no banco de dados ao armazenar resultados de consultas na memória.
- Kinsta CDN entrega ativos estáticos a partir de localizações de borda distribuídas.
Essas camadas trabalham em conjunto para minimizar as solicitações que chegam às threads PHP e ao banco de dados.
Edge Caching por meio do Cloudflare
A rede global de borda do Cloudflare entrega páginas HTML armazenadas em cache com base em chaves de cache que consideram:
- URL e parâmetros de consulta
- determinados cookies
- estado de autenticação
- cookies de carrinho e sessão do WooCommerce
Isso evita que o conteúdo personalizado seja fornecido aos usuários errados.
Regras de bypass de cache também impedem o armazenamento em cache de conteúdo dinâmico que precisa permanecer atualizado, como áreas administrativas do WordPress ou páginas de checkout do WooCommerce.
A diferença de desempenho é significativa, solicitações atendidas pelo Edge Caching ignoram completamente as threads PHP e nunca chegam à instalação do WordPress. Um site em que 80% das solicitações são atendidas pelo Edge Caching precisa de threads PHP apenas para os 20% restantes do tráfego.
Cache de objetos com o Redis
A Kinsta fornece o Redis como um complemento em vez de exigir plugins de terceiros, o que pode garantir que o Redis funcione com o sistema de cache de objetos do WordPress.
O Redis armazena os resultados das consultas ao banco de dados na memória, de modo que o servidor não precisa repetir a execução dessas consultas.
O Redis é um multiplicador de desempenho para sites bem estruturados, e não uma solução para consultas pesadas ou tabelas não indexadas.
O Redis ajuda quando:
- Muitos usuários carregam os mesmos dados, como artigos, produtos ou categorias
- Lojas WooCommerce realizam consultas frequentes de categorias ou verificações de produtos
- APIs repetem consultas idênticas
No entanto, o Redis não acelera a lógica PHP inerentemente lenta, bloqueando chamadas de API externas ou loops mal otimizados.
Kinsta CDN para entrega global de ativos
O CDN da Kinsta fornece ativos estáticos de mais de 260 localizações globais. Essa abordagem reduz a latência para visitantes internacionais e elimina o carregamento de ativos estáticos do seu servidor de origem. Ela também converte automaticamente as imagens para o formato WebP quando os navegadores o suportam.
Cabeçalhos de controle de cache determinam por quanto tempo os ativos permanecem armazenados no CDN. É possível configurar a duração do cache para diferentes tipos de ativos com base na frequência de alterações. Arquivos CSS principais, por exemplo, podem utilizar períodos de cache mais longos. A limpeza do cache, tanto do CDN quanto do Edge Caching, é feita pelo MyKinsta, de forma individual ou conjunta.
Entre o CDN da Kinsta e o cache do Edge, você pode lidar com páginas HTML, conteúdo dinâmico e ativos estáticos. Juntos, eles garantem que a maioria das solicitações nunca chegue ao seu servidor de origem ou consuma threads PHP.
Isolamento de contêineres: resolvendo o problema do “vizinho barulhento”
Os ambientes de hospedagem compartilhada geralmente sofrem quando um site consome muitos recursos. A Kinsta evita esse problema por completo por meio do isolamento com contêineres LXD, fornecendo a cada site:
- CPU dedicada
- RAM dedicada
- Sistema de arquivos isolado
- Stack de software independente
Outros sites não podem “roubar” seus recursos, e problemas em um contêiner não afetam os demais.
Os contêineres são executados em hardware de computação otimizado, garantindo desempenho estável e previsível, mesmo durante picos de tráfego.
Escalando de acordo com as necessidades do seu site
Quando seu site passa a exigir consistentemente mais recursos do que o plano atual oferece, existem opções para escalar verticalmente dentro do próprio contêiner.
Por exemplo, o complemento de desempenho do PHP fornece threads adicionais e mais memória para sites que precisam de maior capacidade computacional.
Também é possível migrar para um plano de nível superior, aumentando os recursos alocados ao contêiner, o número de threads e a memória por thread. Isso é indicado para sites que estão ultrapassando a capacidade do plano atual.
O ponto-chave é entender se você precisa de otimização ou de mais capacidade. Se as threads atingem o limite, mas o uso de CPU permanece baixo, o problema são consultas lentas ou chamadas externas de API, não a quantidade de threads. Adicionar mais threads sem corrigir a execução lenta apenas faz com que mais solicitações aguardem por processos demorados.
Resumo
O gerenciamento de threads PHP, o cache em múltiplas camadas e o isolamento por contêiner desempenham papéis fundamentais no desempenho do WordPress em escala. Entender como as threads funcionam e como o cache reduz a carga que elas precisam processar facilita a escolha do plano correto e a otimização eficaz do site.
Se você está pronto para ver como a infraestrutura da Kinsta lida com suas cargas de trabalho do WordPress, explore hoje mesmo a plataforma de hospedagem gerenciada da Kinsta.
