Sua loja online sobrevive às semanas tranquilas de outubro em um plano de hospedagem feito para tráfego comum. A Black Friday não pede permissão antes de multiplicar esse tráfego por dez ou vinte vezes em uma única hora. Testar a carga antes de novembro mostra onde sua pilha cede: a página de checkout, o banco de dados, o servidor de imagens ou o próprio plano de hospedagem. Ignore isso e você descobrirá ao vivo, na frente de clientes pagantes, no único dia em que uma página lenta custa mais caro. Esta peça cobre quais ferramentas realmente funcionam, quanto custam, em que ordem testar e onde os sites WordPress tendem a falhar primeiro.
O que o tráfego da Black Friday realmente faz a um site
Uma terça-feira normal envia um gotejamento de visitantes que navegam, adicionam um item e saem. A Black Friday envia uma multidão que aterrissa nas mesmas cinco páginas de produto minutos após o envio do seu e-mail de desconto. O servidor trata cada visita como uma solicitação nova: uma consulta de banco de dados, um cálculo de carrinho, uma gravação de sessão. Cada camada da pilha, o servidor web, PHP, banco de dados, gateway de pagamento, tem um limite.
Quando a multidão ultrapassa esse limite, as páginas ficam lentas e o checkout atinge o tempo limite. Alguns desses visitantes saem sem comprar nada e raramente voltam para tentar novamente mais tarde. O teste de carga encontra o limite em outubro, enquanto ainda há tempo para aumentá-lo, em vez de em novembro, quando a única opção é assistir à falha em tempo real.
Ferramentas de teste de carga e o que elas realmente custam
Três ferramentas surgem repetidamente para este trabalho: Apache JMeter, k6 e Gatling. O JMeter é gratuito e ainda é a resposta padrão para muitas equipes de QA corporativas, mas executá-lo bem ainda exige um ambiente próximo o suficiente da produção para fazer sentido, geradores de carga que não sejam o laptop de alguém e uma conta que cresce com o tráfego que você simula.
O k6, motor de teste de carga da Grafana, resolve parte desse problema. O motor k6 é totalmente de código aberto sob a licença AGPL-3.0 e gratuito para execução local ilimitada, então você pode rodar qualquer número de usuários virtuais em seu próprio hardware sem custo. Uma única máquina bem equipada geralmente consegue conduzir dezenas de milhares de usuários virtuais por conta própria, o que cobre a maioria das lojas independentes.
O custo aparece assim que você precisa de escala ou locais de teste distribuídos. O Grafana Cloud cobra pelo k6 a $0.150 por hora de usuário virtual após um nível gratuito mensal de 500 horas. Faça um teste moderado: 500 usuários virtuais por 30 minutos, executado duas vezes por semana. Essa execução é de 250 horas de usuário virtual, e o mês totaliza 2,000 VUh. Faça as contas e o Grafana Cloud k6 Pro chega perto de $244 por mês, o plano de equipe da Artillery Cloud cobra um valor fixo de $199 independentemente do uso, e o plano Enterprise Team da Gatling converte-se em cerca de $413 por mês, embora o plano de equipe da Gatling permita apenas 5 horas de teste por mês.
Dimensione o teste para algo mais próximo de um ensaio real de Black Friday, digamos 10,000 usuários virtuais por duas horas, e o preço muda com isso. O Grafana Cloud k6 é listado a cerca de $0.15 por hora de usuário virtual em seu nível Pro, o que resulta em cerca de $3,000 por 20,000 horas de usuário virtual. Esse ensaio único pode custar mais do que um mês de hospedagem, e é por isso que a maioria das lojas testa uma vez seriamente antes de novembro em vez de toda semana.
O que testar primeiro e em que ordem
Comece com o fluxo de checkout, não com a página inicial. Uma página inicial que carrega lentamente irrita as pessoas; um checkout que falha perde a venda diretamente, por isso merece o primeiro teste. Simule o caminho exato que um comprador faz: página do produto, adicionar ao carrinho, formulário de endereço, etapa de pagamento, página de confirmação.
Teste o gateway de pagamento separadamente e no modo sandbox antes de combiná-lo com o restante do fluxo. Os provedores de pagamento limitam as chamadas de sandbox muito mais agressivamente do que o tráfego real, e um teste de carga que inunda o sandbox pode acionar esse limite e produzir falhas falsas que não têm nada a ver com seu próprio servidor. Execute o teste combinado completo duas a três semanas antes da Black Friday, não na semana da, para que haja tempo de corrigir o que o teste encontrar e executá-lo novamente.
Aumente o tráfego simulado rapidamente, em vez de gradualmente. O tráfego real da Black Friday chega em uma explosão, acionado por um envio de e-mail ou uma postagem social, não uma subida lenta ao longo de uma hora. Um teste que aumenta suavemente esconde o modo exato de falha que você está tentando capturar.
Onde os sites WordPress realmente quebram
A maioria das falhas no WordPress remonta a um dos três limites, e nenhum deles aparece até que o pico de tráfego aconteça. O PHP-FPM, o gerenciador de processos que executa o PHP na maioria dos planos de hospedagem, limita o número de solicitações simultâneas que ele manipulará de uma só vez. Hospedagens compartilhadas de baixo custo e planos VPS pequenos geralmente definem esse limite em um dígito, o que significa que o décimo visitante a acessar o site no mesmo segundo simplesmente espera ou o tempo limite expira.
O banco de dados conta uma história semelhante. MySQL e MariaDB limitam o número de conexões abertas, e uma instalação WordPress cheia de plugins pode esgotar esse limite apenas com tráfego normal, antes que um único visitante atraído por desconto apareça. Plugins de cache e CDNs ajudam enormemente, mas apenas para páginas que podem armazenar em cache. Um banner de venda com cronômetro de contagem regressiva ao vivo, um contador de estoque em uma página de produto ou uma mensagem personalizada de "itens restantes" podem forçar uma página de volta ao modo de consulta de banco de dados completa e sem cache no momento exato em que o tráfego atinge o pico.
O que corrigir primeiro e o que pode esperar
Corrija o checkout e o fluxo de pagamento antes de qualquer outra coisa. Esse é o passo onde uma falha custa dinheiro diretamente, e é também o passo onde a maioria dos testes de carga revela problemas primeiro. Aumente os limites de trabalhadores PHP-FPM e os limites de conexão do banco de dados em seguida, já que ambos são geralmente uma alteração de configuração de uma linha, não uma migração.
Elementos dinâmicos como contadores de estoque ao vivo e cronômetros de contagem regressiva podem esperar, ou ser trocados por uma versão em cache mais simples para o período de promoção. Um crachá simples de "quase esgotado" que é atualizado a cada poucos minutos custa muito menos capacidade do servidor do que um contador ao vivo, e os compradores raramente notam a diferença. Execute um teste de carga real em outubro, corrija o que ele encontrar, depois execute-o novamente duas semanas depois para confirmar que a correção se manteve.
