Como Gerar Padrões de Tráfego Realistas para Aplicações Empresariais

A maioria dos testes de carga em empresas começa com um número escolhido em uma reunião. Cinco mil usuários virtuais. Dez mil. O teste passa, o relatório é arquivado, e a aplicação ainda cai na primeira segunda-feira do trimestre.

Números redondos são fáceis de concordar e quase não dizem nada. O tráfego real chega em rajadas, se divide desigualmente entre recursos e muda sua mistura exatamente no momento em que o volume atinge o pico. Um teste que envia uma parede plana de requisições idênticas executa um caminho de código diferente do que a produção faz, com comportamento de cache, planos de consulta e contenção de bloqueios que não têm relação com o sistema ao vivo.

Aqui está como construir um modelo de tráfego a partir dos dados que você já coleta, e como executá-lo para que os resultados tenham significado.

Índice

1. O Que Torna o Tráfego Empresarial Difícil de Imitar
2. Onde os Dados de Tráfego Já Estão
3. Como Construir um Modelo de Tráfego a Partir dos Dados de Produção
4. Onde os Modelos de Tráfego Erram
5. Como São os Formatos Reais do Tráfego Empresarial
6. Como Executar o Modelo no LoadView
7. Como Conferir o Modelo com a Produção
8. Conclusão
9. Perguntas Frequentes

O Que Torna o Tráfego Empresarial Difícil de Imitar

Três coisas complicam as equipes que vão direto de um número de pessoal para um teste em execução.

Concorrência e taxa de chegada não são o mesmo número. Quando um interessado diz “precisamos lidar com 5.000 usuários”, pergunte a qual dos dois ele se refere. Cinco mil pessoas conectadas simultaneamente é um teste completamente diferente de cinco mil sessões iniciando a cada hora. Errar para mais e você passará semanas ajustando para uma carga que nunca chegará. Errar para menos e o teste não lhe dirá nada. Teste de usuário concorrente só faz sentido quando você sabe qual desses dois números está mirando. Essa é a divisão entre um modelo orientado por taxa de chegada, que reflete como os usuários realmente aparecem, e um modelo orientado por concorrência, que mantém uma população fixa no sistema. O tráfego público é quase sempre o primeiro. Sistemas com base de usuários limitada — desktops de call center, licenças, portais de agentes — realmente se comportam como o segundo.

O tráfego tem uma forma, e essa forma causa o impacto. Pools de conexão, grupos de escalonamento automático e servidores de aplicação preparados sob demanda respondem à taxa de mudança, não apenas ao teto. Um sistema que suporta 2.000 usuários concorrentes confortavelmente pode falhar ao chegar em 2.000 se isso ocorrer em noventa segundos.

A mistura de transações se move com o volume. No volume médio, um site de ecommerce vê principalmente navegação. Durante uma venda relâmpago, as chamadas de finalização de compra e inventário ocupam uma fatia muito maior do mesmo número de requisições. O número total parece idêntico em um painel. A carga no banco de dados não.

Um número fixo de usuários virtuais e uma curva de chegada modelada podem produzir a mesma taxa média de transferência enquanto estressam partes totalmente diferentes da pilha.

Onde os Dados de Tráfego Já Estão

Você não precisa de instrumentação nova. A maior parte disso já está sendo registrada em algum lugar no disco. O trabalho é juntar isso em sessões e filtrar o tráfego bot antes de contar qualquer coisa.

Aplicativos empresariais internos geralmente não possuem tags de analytics. Logs de autenticação e logs do servidor de aplicação cobrem a lacuna — eventos de login dão a taxa de chegada, e o tempo entre a primeira e última requisição por sessão dá a duração.

Como Construir um Modelo de Tráfego a Partir dos Dados de Produção

Quatro saídas definem o modelo: taxa de chegada, mistura de transações, distribuição de tempo de reflexão e divisão geográfica.

Passo 1: Escolha a Janela Exata que Você Está Modelando

Não “o pico de tráfego”. Uma hora específica, numa data específica, extraída dos seus logs. Pegue a hora com maior throughput dos últimos doze meses e depois escolha uma segunda janela cobrindo seu pior evento comercial — fechamento mensal, matrícula aberta, Black Friday, relatórios trimestrais. Modele ambos. Eles quase nunca têm o mesmo formato.

Passo 2: Conte Sessões, Não Requisições

Requisições por segundo é o número mais fácil de extrair e o menos estável. Lance uma atualização front-end que agrupa três chamadas API em uma só e sua contagem de requisições cai um terço sem alteração na demanda. Sessões por hora acompanham o que os usuários realmente fazem. A diferença é maior em aplicações de página única, onde um clique pode desencadear uma dúzia de chamadas API em segundo plano.

Extraia sessões por hora para sua janela, além da média e do percentil 90 da duração da sessão. Guarde ambos os números — a cauda importa no passo três.

Passo 3: Converta Sessões em Concorrência

A Lei de Little conecta taxa de chegada a concorrência:

Sessões concorrentes = sessões por hora × (média de minutos por sessão ÷ 60)

18.000 sessões/hora × (6 minutos ÷ 60) = 1.800 sessões concorrentes

Executar 18.000 usuários virtuais concorrentes contra essa aplicação testa algo dez vezes maior que seu pico real. Você falhará em um teste que passaria, e passará um sprint perseguindo um gargalo que a produção nunca alcançaria.

A Lei de Little usa a média, então trate o P90 como uma verificação separada de dimensionamento e não como uma segunda leitura da fórmula. Insira um P90 de 22 minutos contra a média de 6 minutos e você terá cerca de 6.600 — a concorrência que você teria se cada sessão durasse o mesmo que os dez por cento mais lentos. Deliberadamente pessimista e o número a ser usado para planejamento de capacidade quando sessões longas seguram recursos escassos como threads de relatório ou conexões de banco de dados.

Passo 4: Divida o Tráfego em Transações de Negócio

Agrupe endpoints em transações de negócio ao invés de URLs: busca, visualização de detalhe, adicionar ao carrinho, enviar reclamação, exportar relatório, rodar folha de pagamento. Depois registre duas misturas — a fatia de tráfego de cada transação ao longo da janela inteira, e a fatia no minuto mais movimentado.

Se essas duas misturas diferirem mais do que alguns pontos percentuais em qualquer transação, modele ambas no teste e execute como cenários separados. Um teste baseado só na mistura horária irá subcarregar qualquer transação que tiver pico mais forte.

Passo 5: Extraia o Tempo de Reflexão de Sessões Reais

Não adivinhe o tempo de reflexão e não use um valor constante. Uma pausa fixa de cinco segundos sincroniza todos os usuários virtuais numa coluna marchando em uníssono, produzindo throughput pontiagudo que nenhuma população real gera.

Extraia o intervalo entre carregamentos consecutivos de páginas dentro das sessões reais a partir de dados RUM ou APM e reproduza como uma distribuição. Usuários empresariais tendem a ser bimodais: intervalos curtos navegando num fluxo que conhecem de cor, intervalos longos lendo um documento ou atendendo um telefonema.

Passo 6: Ajuste a Rampa para o Formato Real

Trace contagens de sessões por minuto pela sua janela e molde a rampa do teste para coincidir. Três formatos cobrem a maioria das aplicações empresariais:

• Quase vertical. Lançamentos de produtos, vendas limitadas, abertura de mercado. O pico de concorrência chega em menos de dois minutos.
• Escada. Aplicações internas ativando às 9h em cada fuso horário, um degrau por região.
• Onda quadrada. Tráfego batch e de integração. Ligado em volume total, desligado em volume total, sem rampa.

Passo 7: Coloque a Carga Onde Seus Usuários Estão

Use a divisão geográfica das análises ou logs CDN e gere carga dessas mesmas regiões. Isso não é só para medir latência para usuários distantes. Latência afeta a concorrência: uma sessão mantida aberta por uma viagem de 280 ms dura mais que a mesma sessão numa conexão de 20 ms, então taxas idênticas de chegada produzem maior concorrência. Testar tudo de uma única região esconde isso completamente.

Onde os Modelos de Tráfego Erram

Um conjunto de dados para cada usuário virtual. Mesmo login, mesmo ID de produto, mesma conta em dez mil usuários, e sua taxa de acerto de cache vai para quase 100%. A produção não se comporta assim. Parametrize com um conjunto de dados amplo o suficiente para representar a cardinalidade real — um pool de contas, uma lista de SKUs, IDs únicos de pedido por execução — e compare a taxa de acerto do cache do teste com a produção antes de confiar no resultado.

Nada mais rodando durante o pico. Picos em empresas colidem com trabalhos agendados: ETL noturno, reconstrução de índices, geração de relatórios, janelas de backup, sincronização de replicação. Se o trabalho de reconciliação roda às 2 da manhã e seu pico batch integra também é às 2 da manhã, um ambiente de teste limpo sem carga de fundo mede um sistema que você não opera.

Testes apenas em protocolo em aplicações que dependem fortemente do navegador. Um teste em nível HTTP reproduz as requisições capturadas na gravação. Não executa JavaScript, não aciona chamadas carregadas sob demanda, não dispara tags de terceiros nem renderiza nada. Para uma aplicação de página única ou portal interno pesado, isso deixa de fora a maior parte do trabalho que o cliente realmente faz — e todo o trabalho que determina o que o usuário vê. Testes de carga em aplicações web em navegadores reais são a única forma de medir a renderização do lado cliente sob carga.

Só o caminho feliz. Tráfego real inclui carrinhos abandonados, loops de botão voltar, logins falhos, tokens expirados e cliques duplos impacientes. Logins falhos merecem um cenário próprio: afetam o provedor de identidade, geralmente ignoram cache e frequentemente disparam lógica de bloqueio que adiciona gravações.

Como São os Formatos Reais do Tráfego Empresarial

Três padrões que surgem constantemente, e o que cada um exige do modelo.

Venda Relâmpago no Varejo ou Lançamento de Produto

A chegada é quase vertical e a mistura colapsa em três transações: detalhe do produto, adicionar ao carrinho, finalizar compra. Se a página do produto é cacheável, a taxa de acertos no CDN realmente melhora porque todos solicitam o mesmo item quente, o que torna um teste ingênuo aparentemente fácil. A pressão recai nas chamadas não cacheáveis — verificações de inventário, gravações no carrinho, autorização de pagamento — todas acessando a origem ao mesmo tempo com contenção a nível de linha num único SKU. Modele a mistura no minuto de pico, não na hora.

Fechamento Mensal em um ERP Interno

O volume de sessões é comum. O comprimento das sessões não. Exportações de relatórios e lançamentos batch duram minutos, então a concorrência sobe mesmo que a taxa de chegada pareça estável — a Lei de Little trabalhando contra você. Também ocorre junto com o lote de fechamento contábil, então a carga de fundo faz parte do teste. Separe os usuários de relatório e lançamento de longa duração em sua própria classe de transação com sua própria duração ao invés de incluir tudo numa média única.

Matricula Aberta em Seguro

Semanas de carga elevada com um pico agudo nos dois últimos dias. Sessões prolongadas porque pessoas leem documentos do plano, são pesadas em autenticação e downloads. A parte de várias semanas é teste de resistência, onde vazamentos de memória, exaustão de pool de conexões e volume de logs importam mais que a concorrência máxima. O pico dos dias finais precisa de modelo próprio.

Como Executar o Modelo no LoadView

Uma vez que o modelo exista, o setup do teste segue a partir dele. LoadView oferece três curvas de carga, e seu modelo indica qual escolher:

Grave o fluxo da sessão com o EveryStep Web Recorder para que o script percorra o mesmo caminho do usuário, em um navegador real, nas versões desktop e mobile mostradas nas suas análises. Defina a divisão regional usando a rede de injeção de carga geo-distribuída para coincidir com o passo sete do seu modelo.

Para aplicações que nunca acessam a internet pública, os injetores on-premises testam carga atrás do seu firewall enquanto reportam para a mesma plataforma — que é como a maioria do tráfego interno de ERP e portais é modelado.

Como Conferir o Modelo com a Produção

Um modelo de tráfego é uma hipótese até você comparar sua saída com o real. Capture o backend enquanto o teste roda — eventos de espera do banco de dados, saturação do pool de conexões, profundidade da fila, atividade de escalonamento automático, taxa de busca na origem do CDN, limitação do provedor de identidade. Esses sinais explicam os números abaixo.

Após o teste, coloque cinco medições lado a lado com a produção para a mesma janela:

1. Throughput por transação. Se o throughput do teste ficar bem abaixo da produção com o mesmo número de usuários, o tempo de reflexão está longo demais ou o script está perdendo chamadas.
2. Percentual da mistura de transações. Desvios aqui significam que a lógica de ramificação do script não combina com o movimento dos usuários.
3. Taxa de acerto de cache. Um teste com 95% contra uma produção com 70% indica que o conjunto de dados é muito limitado.
4. Taxa e tipos de erro. A produção quase sempre tem uma taxa básica de erros. Um teste sem erros geralmente está pulando algo.
5. Duração média da sessão. Valida todo o cálculo de concorrência do passo três.

Entretanto analise seus resultados de teste de carga sobre esses cinco pontos, ajuste o script e refaça. Duas iterações geralmente aproximam o modelo o suficiente para confiar.

Perguntas Frequentes

Conclusão

Um padrão de tráfego realista é definido por quatro medições, não por um único número: quão rápido as sessões chegam, o que essas sessões fazem, quanto tempo os usuários pausam entre ações e de onde eles se conectam. Cada uma dessas informações já está nos seus logs.

Extraia esses quatro, aplique a Lei de Little para obter uma figura de concorrência respaldada em dados, e molde a rampa para combinar com uma hora real ao invés de uma linha reta. Depois valide a execução contra a produção e ajuste conforme necessário. É mais trabalho do que escolher um número redondo de usuários virtuais, mas é a única versão do teste cujo resultado você pode usar.

Teste Seu Modelo de Tráfego em Navegadores Reais

LoadView executa seus fluxos de sessão em navegadores reais de mais de 40 zonas AWS e Azure, com curvas de carga que você pode modelar conforme o padrão de chegada que mediu. Planos de teste de carga empresarial incluem subcontas, SSO e migração de scripts de ferramentas legadas.

Agende uma demo com um engenheiro de performance LoadView para revisar seu modelo de tráfego.