WooCommerce lento com muito acesso: como achar o gargalo na sua VPS

Resposta curta: quando uma loja WooCommerce fica lenta só nas horas de movimento, quase sempre é um recurso finito do servidor que acabou: processo livre do PHP, conexão livre do banco ou CPU. A ordem certa de trabalho é medir qual dos três acabou, resolver o que é ajuste ou cache (custo zero) e só depois pensar em capacidade a mais.

“O site tá lento” não é diagnóstico. Uma loja que abre rápido às 3h da manhã e engasga na promoção das 20h não tem problema de código lento: tem problema de fila. Alguém chegou e não tinha atendente livre. Descobrir qual atendente faltou é o trabalho inteiro.

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 (PHP-FPM é o programa que executa o PHP; ele mantém um número fixo de processos filhos e nada além disso roda em paralelo);
• 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.

No dia normal, sobra de tudo. No pico, o primeiro desses limites a acabar vira a fila. E fila em servidor não degrada devagar: enquanto há processo livre, o site responde normal; quando o último é ocupado, as requisições passam a esperar e a página que respondia rápido passa a demorar ou devolver erro 502/504. É um interruptor, não uma rampa, e é por isso que “a hospedagem não aguenta tráfego” vira a explicação padrão antes de qualquer medição.

Sinal 1: PHP-FPM sem processo livre

O log de erro do nginx passa a mostrar timeout ou server reached pm.max_children. É o sintoma mais comum de VPS travando com muito acesso, e o mais confundido com 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: ative o status do PHP-FPM e olhe a fila de escuta e os processos ativos durante o movimento. Se os ativos batem no teto e a fila cresce, achou.

Sinal 2: banco no limite de conexão

Aparece como Too many connections ou como consulta que demora só quando há gente. O MySQL 8 vem configurado de fábrica com 151 conexões simultâneas, e esse número não tem nada a ver com o tamanho da sua loja: é só o default. Confira o valor real da sua instalação antes de mexer, porque conexão custa memória e subir esse número às cegas troca um erro por outro.

Sinal 3: CPU saturada de verdade

Aí sim é trabalho pesado demais por requisiçã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 cravada com pouca gente no site é desperdício, não falta de máquina.

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.

Checklist: o que verificar, do mais barato ao mais caro

Faça na ordem. A maioria dos casos morre nos primeiros itens, e cada item resolvido muda o diagnóstico dos seguintes.

Custo zero, efeito grande:

1. 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.
2. Cache de objeto. Guarda em memória (Redis ou Memcached) o resultado de consultas que o WordPress repete a cada requisição. É o item que costuma tirar mais peso do banco em loja com muito produto e muito atributo.
3. Peso da página. Imagem em tamanho original, sem WebP e sem lazy load, não derruba o servidor, mas piora a percepção de lentidão e come banda na hora do pico.
4. Plugin e tema. Desative um a um em ambiente de teste e meça. Vale caçar consulta pesada e opção autoload gigante na tabela de opções, dois clássicos de loja antiga. Query Monitor ou o slow query log do MySQL mostram quem é o culpado.
5. Tarefas fora da visita. Tire o wp-cron do fluxo do visitante e passe para o cron do sistema; mova backup, sincronização de ERP e relatório para a madrugada.

Custo zero, mas exige mão de dev:

6. 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.
7. 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.
8. 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.

Custo baixo:

9. 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.

Custo variável, só depois de tudo acima:

10. Capacidade extra durante o pico. É o assunto da próxima seção, e só faz sentido quando os nove itens anteriores já foram feitos.

Magento é diferente?

O caminho de diagnóstico é o mesmo, mas o Magento chega mais rápido no limite de CPU e memória porque é mais pesado por requisição. Ele tem cache de página nativo e integra com Varnish, tem indexadores que precisam estar em modo agendado e não em “atualizar ao salvar”, e tem cron próprio competindo com o tráfego. Magento lento no pico costuma ser cache cheio de invalidação, indexador rodando no horário errado ou modo developer esquecido em produção. Verifique isso antes de qualquer conta sobre servidor.

E quando a loja já está otimizada e ainda não aguenta o pico?

Existe esse caso, e é o único em que capacidade extra é a resposta certa. 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. Comprar máquina permanente para essas horas é pagar o ano todo por um dia.

É esse recorte que o SwarmBurst atende. Ele é um agente de cloud bursting para cluster de contêineres: 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. Passado o pico, o nó é drenado (as réplicas voltam para a VPS antes de a máquina desligar) e encerrado, e a cobrança dele termina ali. 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á. Se a AWS falhar no meio do pico, a loja segue no ar com a capacidade que já tem hoje. 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. A maioria das lojas WooCommerce em VPS não roda assim: roda direto no servidor, com nginx, PHP e MySQL instalados no sistema, sem contêiner nenhum. Se é o seu caso, 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? Resolve a maior parte do catálogo, que é o que gera mais visita. 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 é a única saída, e para pico curto costuma ser a mais cara: migrar tudo troca capacidade fixa barata por capacidade elástica cara e joga fora a VPS que você já paga. Otimizar primeiro e reforçar só nas horas de pico cobre o mesmo problema sem trocar de casa.

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: é mais barato e resolve a maior parte dos casos. 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.

Quero o piloto do primeiro pico