Teste de carga antes da Black Friday: a conta de capacidade da loja Magento

A loja Magento aguenta a Black Friday? Só o teste responde

A Black Friday de 2026 cai em 27 de novembro. A pergunta "quantos acessos o Magento aguenta" não tem número universal: a mesma instalação suporta muito mais visitantes quando o cache de página responde quase tudo, e muito menos quando a campanha manda gente direto para busca, filtro e carrinho, que passam pelo PHP.

Por isso eu não aceito "o servidor é bom" como resposta. O caminho tem três etapas: estimar o pico com dado da própria loja, converter o pico em capacidade com a fórmula da Adobe e provar em homologação, com critério de aprovação escrito antes do teste.

Como estimar o pico da loja a partir do ano anterior

O dado mais útil é o log de acesso do servidor na Black Friday passada. Dele saem dois números:

• Pico de requisições por minuto que chegaram ao PHP, sem as que o Varnish ou a CDN responderam do cache e sem arquivos estáticos. É esse tráfego que consome processador.
• Tempo médio de resposta do PHP nesse mesmo minuto.

Em cima disso entra o fator de crescimento, que é decisão da loja: verba de mídia maior, base de e-mail maior, lançamento de coleção. Não existe fator padrão de mercado; use o seu plano comercial. Sem log do ano anterior, parta das sessões na hora de pico da ferramenta de análise e meça em homologação quantas requisições ao PHP uma sessão gera, com folga maior.

Quantos acessos simultâneos o Magento suporta: a fórmula da Adobe

Nas recomendações de hardware, a Adobe diz que um núcleo de CPU atende em torno de duas requisições do Commerce (às vezes até quatro) e dá a fórmula para processar tudo sem formar fila:

N[Cores] = (N[Expected Requests] / 2) + N[Expected Cron Processes]

A documentação não fixa unidade de tempo para as requisições esperadas. Como a referência é o que um núcleo atende ao mesmo tempo, eu uso requisições simultâneas no PHP e chego a elas pela relação clássica de filas: simultâneas = requisições por segundo x tempo médio de resposta em segundos.

Exemplo ilustrativo, com números fictícios:

Agora a parte que só o teste revela: se, sob carga, o tempo médio sobe para 0,8 s, as simultâneas vão a 36 e a conta pede 36 ÷ 2 + 4 = 22 núcleos. Capacidade e velocidade andam juntas, e a conta de mesa não substitui a medição.

Memória também entra. A Adobe cita 256 MB de memória do PHP para servidor que só atende a vitrine: com 22 processos, o teto teórico é 22 x 256 MB = 5.632 MB, cerca de 5,5 GB só de PHP. Para o banco, a mesma página recomenda memória disponível de, no mínimo, perto da metade do tamanho dos dados.

Roteiro do teste de carga em homologação

1. Ambiente comparável: homologação com a mesma configuração de servidor, cache e busca de produção e cópia do catálogo real. Máquina menor exige conta de proporção e folga maior.
2. Fluxos de compra com peso real: home, categoria com filtro, busca, produto, carrinho e checkout até antes da captura do pagamento, na proporção que o seu analytics mostra.
3. Cache aquecido antes de medir, como estará no dia.
4. Degraus de carga: 50%, 100% e 150% do pico estimado, com alguns minutos em cada degrau.
5. Teste de estresse no fim: subir além de 150% até a loja degradar, para saber onde fica o limite e qual peça quebra primeiro.
6. Nada de pedido real: gateway em modo de teste e e-mails transacionais desligados ou desviados.

Teste em produção, só com janela combinada com a hospedagem e com a CDN: tráfego sintético em volume pode ser bloqueado como ataque. No Adobe Commerce na nuvem, o modelo de responsabilidade compartilhada da Adobe põe o teste de performance da aplicação customizada na conta do lojista.

As métricas que aprovam ou reprovam o teste

O critério de aprovação é escrito antes do teste, com os limites que a loja aceita. Estas são as quatro métricas que eu olho em cada degrau:

O p95 é o tempo abaixo do qual ficam 95% das requisições e mostra o cliente que a média esconde. Na documentação do PHP, listen queue é o número de requisições esperando um processo livre, e max children reached indica se o limite de processos já foi atingido. Reprovou? Corrija o primeiro gargalo e rode de novo: três semanas dão para duas ou três rodadas.

Preparar o Magento para a Black Friday: o que pedir ao suporte agora

• O pico estimado por escrito, com a origem do dado e o fator de crescimento aprovado por você.
• A conta de núcleos e de memória, com a fórmula da Adobe.
• A data do primeiro teste e da nova rodada depois das correções.
• Relatório por degrau com p95, taxa de erro, fila do PHP-FPM e CPU do banco.
• Plano de escala: se faltar servidor, quem contrata, em quanto tempo fica pronto e quem testa de novo.

Se o teste mostrar que o gargalo é tempo de resposta, e não capacidade, a decisão passa a ser de otimização, e aí vale a conta de retorno de otimização de performance no Magento. Performance, com Varnish, Valkey ou Redis e OpenSearch, faz parte do suporte Magento 2.