Antes de um pipeline de coleta ir para produção, alguém razoavelmente pergunta se ele vai se sustentar em volume total. O instinto é executar um teste de carga, e o instinto está certo, mas o teste de carga em proxies tem uma restrição que o teste de carga comum não tem: a coisa contra a qual você está direcionando tráfego geralmente pertence a outra pessoa.
Esse único fato remodela o exercício. Você não está testando se um sistema consegue absorver sua carga, você está caracterizando o comportamento do seu próprio pipeline e encontrando seu teto, sem conduzir um teste de estresse não anunciado contra terceiros. Veja como fazer isso corretamente.
O que você está de fato testando
Separe as quatro questões, porque elas exigem testes diferentes e apenas uma delas envolve um alvo real.
A capacidade do seu próprio pipeline. Quantas requisições concorrentes seus workers, o tratamento de conexões, o parsing e o armazenamento conseguem sustentar antes que algo sature. Este é um teste do seu código e da sua infraestrutura e pode ser executado sem tocar no site de ninguém.
Comportamento do caminho do proxy sob concorrência. Como a latência e a taxa de sucesso se movem à medida que você aumenta as requisições em andamento pelo gateway. Também majoritariamente independente de qualquer alvo específico.
A tolerância do alvo. Qual ritmo um site específico aceita antes de limitar ou desafiar você. Esta é a questão que deve ser abordada com cuidado e de forma incremental, e não com um gerador de carga.
Throughput de ponta a ponta. O que tudo acima produz junto, que é o número do qual seu cronograma de fato depende.
Confundir essas questões produz o resultado clássico e ruim: um “teste de carga” que martela um único alvo, é bloqueado, e não diz nada além de que você pode ser bloqueado.
Teste primeiro contra algo que você possui
Monte um alvo que você controla e que retorna uma resposta de tamanho realista, e direcione o pipeline a ele através dos proxies. Isso isola tudo, exceto o terceiro.
Você aprende uma quantidade surpreendente de coisas aqui. Se seu pool de workers de fato alcança a concorrência que você configurou. Se o tratamento de conexões está fazendo o que você pensa, já que conexões em pool se comportam de forma diferente através de um gateway, conforme IP não rotacionando. Onde seu parsing ou armazenamento se torna o gargalo. E qual distribuição de latência o caminho do proxy adiciona, sem a variabilidade própria de um alvo misturada.
Use tamanhos de payload realistas. Um teste contra um endpoint minúsculo vai superestimar seu throughput seriamente, porque tanto a largura de banda quanto o parsing escalam com o tamanho da resposta e a latência residencial domina de forma diferente em diferentes tamanhos de payload.
Meça as coisas certas
Throughput isolado é um resumo pobre. Cinco medições tornam um teste de carga interpretável.
Taxa de sucesso validada, não sucesso HTTP. Um teste que reporta 100% de sucesso enquanto retorna páginas de desafio está medindo a coisa errada, conforme detectando conteúdo bloqueado ou falso.
Percentis de latência, especificamente p50, p95 e p99. A latência residencial tem uma distribuição ampla, então uma média esconde a cauda que de fato determina se um trabalho com prazo definido termina.
Throughput como função da concorrência, plotado em vez de amostrado em um único ponto. A característica interessante é onde a curva se estabiliza, já que depois disso você está adicionando requisições em andamento sem adicionar conclusões.
Distribuição de classes de erro, porque a mistura diz o que está te limitando. Timeouts apontam para um lado, sinais de taxa para outro, e desafios para outro ainda, conforme erros comuns de proxy residencial.
Bytes por requisição, já que isso determina o custo em volume de produção e é fácil de medir agora e caro de descobrir depois, conforme estimando a largura de banda mensal.
Aumente gradualmente, não em picos
Aumente a concorrência em etapas, mantenha cada etapa tempo suficiente para os números se estabilizarem, e registre o conjunto completo de medições em cada nível. Um teste de pico não diz quase nada útil aqui, porque a falha que ele produz é indistinguível de um alvo reagindo a uma explosão de tráfego.
O padrão que você está procurando é onde o throughput para de subir com a concorrência, e onde a latência p95 começa a subir bruscamente. Essas duas coisas geralmente coincidem e marcam seu teto prático. Execute seu trabalho de produção em algum ponto abaixo dele, e não nele, porque o teto se move com o comportamento do alvo, a hora do dia e as condições do pool.
for concurrency in [5, 10, 20, 40, 80]:
stats = run_step(concurrency, duration_seconds=180) # hold, then record
print(concurrency, stats.validated_success, stats.p50,
stats.p95, stats.rps, stats.bytes_per_req, stats.error_mix)
if stats.validated_success < 0.9 or stats.p95 > LATENCY_BUDGET:
break # found the kneeCalibrando contra um alvo real, com cuidado
Eventualmente você precisa saber o que suas fontes reais toleram, e isso não pode ser aprendido a partir de um mock. Faça isso como calibração, não como teste de carga.
Comece bem abaixo da taxa pretendida e aumente lentamente, observando a taxa de sucesso validada em vez de códigos de status. Pare de aumentar no primeiro sinal de degradação em vez de empurrar até a falha, já que o objetivo é encontrar um ritmo sustentável, não um ponto de ruptura. Espalhe a calibração por um período mais longo do que parece necessário, porque o limitador de taxa é frequentemente aplicado sobre janelas móveis e uma explosão curta pode passar enquanto uma taxa sustentada não passa.
Respeite o que o alvo diz. Um 429 ou um Retry-After é uma instrução direta e a resposta correta é diminuir o ritmo em vez de rotacionar endereços para manter o ritmo, que é a distinção em limitação de taxa e throttling de requisições.
E mantenha isso proporcional: seu tráfego de calibração deve ser um erro de arredondamento em relação à carga normal do site. Estressar deliberadamente a infraestrutura de terceiros não é um exercício de engenharia benigno, e dependendo da escala e da intenção isso pode cruzar para o campo da interferência. Se você precisa saber os limites de um parceiro com precisão, pergunte a ele.
Interpretando os resultados
Traduza a curva nos dois números que sua configuração de produção precisa: um limite de concorrência por alvo e uma taxa por alvo, ambos definidos abaixo do joelho da curva com margem.
Depois, faça uma verificação de sanidade contra seu cronograma. A concorrência decorre da taxa e da latência, então se sua latência p50 medida for mais alta do que você assumiu, a concorrência necessária para um determinado prazo aumenta correspondentemente, que é a aritmética em planejando volume de requisições e concorrência.
Por fim, trate os resultados como perecíveis. As defesas do alvo mudam, as condições do pool variam por hora e por mercado, e um número medido numa semana tranquila não se sustentará durante um pico. Refaça a calibração periodicamente e, mais importante, execute as mesmas medições continuamente em produção para que o teto seja observado, não assumido, conforme monitorando a saúde do proxy em escala.
Conclusão
O teste de carga em proxies é caracterização de capacidade, não um ataque a terceiros. Separe as quatro questões e teste as duas primeiras contra infraestrutura que você possui com tamanhos de payload realistas, o que isola os gargalos reais do seu pipeline da variabilidade de um alvo. Meça a taxa de sucesso validada, os percentis de latência, o throughput em função da concorrência, a mistura de classes de erro e os bytes por requisição, depois aumente em etapas e procure o joelho onde o throughput se estabiliza e o p95 sobe. Calibre contra alvos reais lentamente e pare no primeiro sinal de degradação em vez de empurrar até a falha, respeitando os sinais de taxa ao diminuir o ritmo em vez de rotacionar. Defina os limites de produção abaixo do joelho, rederive sua concorrência a partir da latência medida, e continue medindo em produção porque o teto se move.
O caminho sendo testado são os proxies residenciais, onde concorrência e geografia são parâmetros por requisição em vez de configurações de plano, cobrados por GB de modo que um teste de carga bem dimensionado custa aproximadamente o que sua largura de banda custa.