Revisado em 12/11/2026.
Resposta curta: se o WooCommerce fica lento com muito acesso, compare o tempo de resposta com a fila do PHP-FPM, as conexões e consultas do banco e o uso da VPS durante o pico. Código, plugins, cache e serviços externos também podem ser a causa. Meça antes de comprar capacidade ou alterar limites.
"O site tá lento" não é diagnóstico. Uma loja que abre rápido fora do pico pode acumular fila quando a concorrência cresce. Isso não exclui código ineficiente: uma consulta, plugin ou chamada externa lenta pode ocupar recursos por mais tempo e formar a fila. O diagnóstico precisa ligar o sintoma a uma medição.
Por que a loja abre rápido no dia normal e trava no pico?
Cada visitante que pede uma página não cacheada consome, ao mesmo tempo:
- um processo do PHP-FPM, quando esse é o modo usado pelo servidor para executar PHP; o limite de processos simultâneos depende da configuração do pool;
- uma ou mais conexões com o banco de dados, que também tem um limite configurado;
- uma fatia de CPU e de memória do servidor.
Fora do pico, esses recursos podem ter folga. Com mais concorrência, um limite de atendimento pode formar fila e aumentar a espera. A degradação depende do serviço e pode acelerar perto da saturação. Erros 502 e 504 também podem surgir, mas não identificam a causa sozinhos; por isso é preciso comparar logs e métricas antes de concluir que a hospedagem não aguenta o tráfego.
Sinal 1: PHP-FPM sem processo livre
O nginx pode registrar timeout, enquanto o log do PHP-FPM pode mostrar server reached pm.max_children. Esses sinais não provam falta de CPU: o processador pode estar tranquilo e a loja parada, porque o limite que acabou foi o número de processos, não o de ciclos.
Diagnóstico: configure a página de status do PHP-FPM com acesso restrito ao ambiente interno ou a IPs autorizados. Compare fila de escuta, processos ativos e eventos de limite atingido durante o movimento. Uma fila crescente indica espera por atendimento; ainda é necessário investigar por que os processos estão ocupados. Não exponha esse status publicamente.
Sinal 2: banco no limite de conexão
Aparece como Too many connections ou como consulta que demora só quando há gente. Confira o max_connections real da instalação e compare com Threads_connected, Threads_running e Max_used_connections. O máximo observado é histórico desde a inicialização ou reinicialização dos contadores, não uma medição exclusiva daquele pico. Conexões também consomem recursos; aumentar o limite sem medir pode agravar o problema. Veja as variáveis de status do MySQL.
Sinal 3: CPU saturada de verdade
Entre as hipóteses estão: página sem cache, tema recalculando o carrinho a cada visita, plugin consultando o banco em toda página, wp-cron disparando tarefa junto com a visita. CPU alta com poucos visitantes merece investigação: pode haver consultas caras, tarefas concorrentes, robôs ou capacidade insuficiente para aquele trabalho. A contagem de visitantes, sozinha, não distingue essas hipóteses.
Sinal 4: tudo no mesmo servidor
Numa VPS típica, PHP, banco, Redis, e-mail e backup dividem os mesmos núcleos. Um mysqldump no horário errado compete com o cliente tentando finalizar a compra. Antes de comprar máquina, confira o que mais estava rodando na hora em que a loja caiu.
Tabela de diagnóstico durante o pico
Compare as medições no mesmo intervalo de tempo. Uma captura fora do incidente pode esconder a causa.
| Sintoma | Onde medir | Como interpretar | Próxima ação |
|---|---|---|---|
| Páginas dinâmicas esperam e a fila do PHP cresce | Status e logs do PHP-FPM; tempos do proxy | Os processos não acompanham a chegada de trabalho; não prova falta de CPU | Investigar slowlog, consultas e chamadas externas antes de aumentar o pool |
Too many connections | Logs da aplicação e status do MySQL | O limite de conexões foi alcançado | Conferir uso por aplicação, duração das consultas e memória disponível |
| CPU alta junto do tempo de resposta | Métricas da VPS e processos no mesmo intervalo | Há concorrência por processamento, ainda sem causa atribuída | Separar PHP, banco, tarefas agendadas e tráfego automatizado |
| Uso de swap e resposta degradada | Memória e swap da VPS, logs de processos encerrados | Pode haver pressão de memória | Rever consumo e limites antes de adicionar processos |
| Só o checkout fica lento, mesmo com recursos livres | Tempos de chamadas a frete, pagamento e ERP | Dependência externa pode estar prendendo a requisição | Seguir o diagnóstico de checkout |
| Lentidão coincide com backup ou tarefas | Logs do agendador e métricas no horário | Correlação é uma pista, não prova isolada | Comparar em teste controlado e avaliar outra janela de execução |
Anote horário, URL afetada, carga, métrica e alteração realizada. Mude uma variável por vez em homologação e repita o cenário. A documentação do WooCommerce também recomenda investigar plugins, tema, hospedagem e cache, em vez de assumir uma causa única.
Checklist: o que verificar antes de contratar capacidade
Use os sinais medidos para escolher o próximo item. Cada mudança pode alterar o gargalo; compare novamente depois dela.
Ajustes que podem aproveitar a infraestrutura existente:
- Cache de página. Página cacheada é HTML entregue sem executar PHP e sem tocar o banco, o que tira a visita de catálogo da conta dos processos. Carrinho, checkout e minha-conta não podem ser cacheados: garanta que estão excluídos, ou você vende o carrinho de um cliente para outro.
- Cache de objeto. Guarda em memória (Redis ou Memcached) o resultado de consultas que o WordPress repete a cada requisição. Avalie o efeito nas consultas e no uso de memória, sem presumir ganho antes de medir.
- Peso da página. Imagens grandes podem aumentar transferência e tempo de carregamento. Confira tamanho, formato, cache e carregamento adequado; compare o tempo do servidor com a experiência do navegador.
- Plugin e tema. Desative um a um em ambiente de teste e meça. Vale caçar consulta pesada e opção
autoloadgigante na tabela de opções, dois clássicos de loja antiga. Query Monitor ou o slow query log do MySQL mostram quem é o culpado. - Tarefas fora da visita. Avalie executar tarefas por agendador do sistema, com configuração e acompanhamento próprios, e escolher janelas para backup e integrações conforme a operação. Não desative o agendamento atual antes de garantir o substituto.
Configuração que exige avaliação técnica:
- Ajuste do PHP-FPM. O número de processos filhos tem que caber na memória da VPS: cada processo consome RAM, e configurar mais do que a máquina suporta troca lentidão por swap, que é pior. Não existe valor universal, depende do consumo por processo da sua loja. Ligue também o OPcache, que evita recompilar o PHP a cada requisição.
- Ajuste do banco. Reveja o limite de conexões junto com o tamanho do pool de cada aplicação que fala com ele, e confira índice nas tabelas que o slow query log apontou.
- CDN na frente. Serve imagem, CSS e JS de fora da sua VPS. Existem planos gratuitos que resolvem o problema de banda e de estático.
Ampliação permanente de capacidade:
- Subir o plano da VPS. Se a loja já está otimizada e o pico é só um pouco maior que a máquina, dobrar a VPS pode ser a solução mais simples e mais honesta. A desvantagem é conhecida: você paga o mês inteiro por capacidade que usa poucas horas.
Capacidade temporária, quando o diagnóstico justificar:
- Capacidade extra durante o pico. É o assunto da próxima seção. Considere quando as medições mostram que a parte escalável da aplicação precisa de recursos adicionais, comparando o esforço com outras opções.
Este diagnóstico serve para outras plataformas?
A separação entre aplicação, banco e dependências também ajuda em outras lojas, mas métricas, processos e configuração variam. Um ajuste específico de WooCommerce ou PHP-FPM não deve ser copiado para outra arquitetura sem conferir a documentação e o comportamento real.
E quando a loja já está otimizada e ainda não aguenta o pico?
Existe esse caso. Também é possível combinar otimização e expansão quando o diagnóstico justifica as duas ações. Cache ligado, plugin revisado, banco ajustado, e ainda assim sobram algumas horas no mês em que o movimento passa do que a VPS entrega. Compare ampliar a VPS com capacidade temporária, incluindo implantação, operação, rede e cobrança dos recursos utilizados.
É esse recorte que o SwarmBurst atende. Ele é um agente de cloud bursting para Docker Swarm: fica instalado na sua VPS, acompanha o uso do cluster e, quando o movimento passa do ponto que você definiu, sobe instâncias EC2 na sua conta AWS. Essas instâncias entram no cluster por um túnel WireGuard e passam a atender junto com a VPS. A redução de capacidade exige drenar o nó, conferir as tarefas substitutas e encerrar a instância. Outros recursos da conta, como volumes mantidos, podem continuar gerando cobrança. Você define um teto de gasto mensal, recebe alerta por e-mail e no painel antes de chegar nele, escolhe a região (incluindo São Paulo, sa-east-1) e vê o histórico de cada evento. A VPS continua sendo o servidor principal e a dona do estado: banco, arquivos enviados e painel não saem de lá. A VPS permanece como base, mas isso não garante disponibilidade durante falhas: o impacto depende da carga, das dependências e da capacidade restante. Tem mais detalhe na página inicial.
O pré-requisito que precisa estar claro antes de qualquer conversa
O SwarmBurst só funciona se a sua loja rodar em contêineres, num cluster. Se a sua loja roda diretamente na VPS, com nginx, PHP e MySQL instalados no sistema, sem contêineres, existe um passo anterior de colocar a loja em contêiner e organizar o que fica fixo na VPS (banco, Redis, uploads, frontend) e o que pode ganhar réplica nos nós temporários (o backend). Esse passo é trabalho de verdade, não checkbox de instalação, e ele entra no diagnóstico antes de qualquer proposta.
E o que não vendemos: migração de servidor e hospedagem. Sua loja continua onde está.
Perguntas frequentes
Quanto de acesso derruba uma VPS? Não existe esse número. O que derruba é o cruzamento entre o trabalho que cada visita gera na sua loja e o recurso que acabou primeiro. Duas lojas na mesma VPS, uma com cache de página e outra sem, aguentam volumes bem diferentes. A resposta vem de medir a sua, não de tabela.
Cache resolve tudo? Pode absorver páginas públicas de catálogo quando são elegíveis ao cache e a configuração está correta. Não resolve carrinho, checkout e área do cliente, justamente as páginas que precisam funcionar quando a promoção dá certo. Quando a loja virtual não aguenta pico de acesso mesmo com cache ligado, é aí que costuma estar o gargalo.
Preciso migrar da minha VPS para a nuvem? Não. Compare otimização, ampliação da VPS e expansão para outra infraestrutura com seus custos e requisitos reais. Manter a VPS e adicionar capacidade temporária é uma alternativa quando a aplicação e as dependências permitem.
Vocês têm caso de cliente para mostrar? Não. O SwarmBurst já sobe e desliga instância real na AWS em teste validado, mas ainda não passou pelo pico real de uma loja de verdade, e não temos depoimento nem número de cliente para exibir. Não vamos inventar nenhum. É exatamente por isso que a implantação do piloto é gratuita ou simbólica.
O que é o Piloto do Primeiro Pico? Uma troca direta: um piloto por vez, implantação gratuita ou simbólica combinada caso a caso, e em troca você autoriza medir e publicar os dados reais de performance do pico e dá um depoimento no fim, se a experiência tiver sido boa. Se no diagnóstico o seu caso não encaixar, dizemos isso na hora em vez de vender.
Se a loja já está otimizada e ainda cai no pico, vale conversar
Se você ainda não fez o checklist, faça o checklist: ele ajuda a identificar onde vale investir. Se já fez tudo e a loja continua batendo no teto algumas horas por mês, é aí que capacidade por hora faz sentido, e é esse o caso que procuramos para o piloto.