Como Planejar Volume de Requisições e Concorrência em Proxies Residenciais

Muitas perguntas sobre capacidade chegam de trás para frente. Alguém pergunta quantas threads rodar ou quanta largura de banda comprar, quando nenhuma das duas pode ser conhecida até que você tenha traduzido o requisito real, que geralmente é algo como “cinquenta mil registros de produtos, atualizados diariamente, prontos até as 08:00”. Essa frase contém tudo o que você precisa. Veja aqui como transformá-la em volume de requisições, concorrência e tamanho de plano, e onde a restrição realmente se impõe.

Comece pelos registros, não pelas requisições

A primeira conversão é a que as pessoas pulam, e é onde as estimativas erram por múltiplos.

Um registro raramente equivale a uma requisição. Um registro de produto pode precisar de uma página de listagem mais uma página de detalhes, ou seja, duas. Se a listagem tiver paginação e você precisar de todos os itens, adicione as requisições de paginação, amortizadas entre os registros que elas produzem. Se uma página de detalhes carrega seus dados a partir de uma segunda chamada, essa é mais uma. E se você renderiza páginas em um navegador em vez de buscar endpoints de dados, uma requisição lógica se transforma em dezenas de buscas de recursos, o que importa enormemente para a largura de banda, mesmo quando não altera a contagem lógica.

Então escreva isso explicitamente:

requests_per_record = detail_pages + (listing_pages / records_per_listing) + extra_calls

Para cinquenta mil registros a, digamos, 1,2 requisições cada, isso são 60.000 requisições por execução. Depois adicione uma margem para falhas, porque sua taxa de sucesso validada não é 100%. A 90%, você precisa de aproximadamente 67.000 tentativas para obter 60.000 sucessos, e se você também estiver repetindo falhas transitórias, o número real é um pouco maior ainda. Planejar com base em tentativas em vez de sucessos é o segundo erro de estimativa mais comum.

A concorrência decorre da taxa e da latência

Agora a parte que surpreende as pessoas. Concorrência não é um número que você escolhe livremente; ela decorre de quão rápido você precisa ir e de quanto tempo cada requisição leva.

Se você precisa concluir 67.000 requisições em uma janela de quatro horas, isso equivale a cerca de 4,7 requisições por segundo sustentadas. Requisições residenciais são mais lentas que as diretas, então assuma uma média de dois segundos por requisição de ponta a ponta. A quantidade de requisições em andamento que você precisa é simplesmente a taxa multiplicada pela latência:

concurrency = requests_per_second x average_latency_seconds
            = 4.7 x 2
            ~ 10 concurrent requests

Essa relação vale a pena internalizar, porque ela explica duas coisas ao mesmo tempo. Alvos mais lentos precisam de mais concorrência para a mesma vazão, e é por isso que um alvo que se degrada silenciosamente pode esvaziar um cronograma sem que nenhum erro apareça. E aumentar a concorrência não aumenta a vazão se o alvo é o que está desacelerando você; isso apenas aumenta o número de requisições esperando.

Trabalhe isso também no sentido contrário. Se você limitar a concorrência em 10 e a latência se deslocar de dois segundos para cinco, sua vazão cai de 5 requisições por segundo para 2, e um trabalho de quatro horas se torna um de dez horas. Construir o cronograma com margem, em vez de no limite, é o que impede que um deslocamento de latência se torne um prazo perdido.

A restrição é o alvo, não a sua máquina

Aqui é onde o planejamento encontra a realidade. A concorrência que sua infraestrutura consegue sustentar quase nunca é o limite vinculante. O que vincula é o que o alvo tolera.

Limites de taxa são aplicados por IP e, cada vez mais, por alvo de forma agregada. Um pool permite distribuir a carga por IP, mas o total que chega a uma única origem ainda é visível, então o número a ser planejado é o que aquele site aceita, e não o que seus workers conseguem emitir. A mecânica de ritmo está em rate limiting e throttling, e a questão de distribuição que vem em seguida, quanta dispersão seu volume precisa, é abordada em quantos IPs de proxy você realmente precisa.

Na prática, isso significa que seu plano deve conter um limite de concorrência por alvo e uma taxa por alvo, não uma configuração global única. Cinquenta alvos com concorrência modesta cada um é uma proposta completamente diferente do mesmo total direcionado a um único site, e apenas a segunda opção resulta em bloqueio.

Largura de banda é o número que você realmente compra

Como proxies residenciais são cobrados por dados transferidos, o tamanho do plano decorre dos bytes, e não das requisições ou dos endereços.

monthly_bandwidth = attempts_per_run x runs_per_month x average_bytes_per_response

A variável que domina é a última, e ela está inteiramente sob seu controle. Uma resposta JSON ou uma página HTML enxuta tem dezenas de kilobytes; uma página totalmente renderizada com imagens, fontes e scripts de terceiros tem vários megabytes. Com 60.000 requisições diárias, respostas de 50 KB somam aproximadamente 90 GB por mês, enquanto páginas renderizadas de 2 MB somam cerca de 3,6 TB, a partir da mesma carga de trabalho lógica. Essa é a diferença entre um plano modesto e um empresarial, e é decidida por você buscar dados ou renderizar páginas, conforme quando você precisa de um navegador headless e reduzindo custos de largura de banda.

Faça essa otimização antes de dimensionar o plano, porque isso frequentemente faz você descer um nível. O método de previsão mais completo está em estimando a largura de banda mensal, e as escolhas em nível de produto em escolhendo o plano certo.

Agendamento: espalhar é melhor que concentrar

Dois trabalhos com volume diário idêntico podem se comportar de forma completamente diferente dependendo de quando são executados.

Comprimir tudo em uma janela de uma hora multiplica sua taxa instantânea contra cada alvo de uma só vez, o que é precisamente o formato que aciona defesas. Espalhar o mesmo trabalho pela janela disponível reduz a taxa por alvo de graça, e também dá espaço para que falhas sejam repetidas mais tarde na execução, em vez de se acumularem no final.

Requisitos de atualidade definem a restrição. Se os dados precisam estar atuais até as 08:00, você precisa coletá-los antes disso, mas isso é um prazo, não uma instrução para começar às 07:00. Onde o cronograma permitir, espalhar por toda a janela e priorizar as fontes mais voláteis mais cedo é estritamente melhor.

Valide com um piloto antes de se comprometer

Todo número acima é uma hipótese até que você meça as duas variáveis que assumiu: a latência média real nos seus alvos reais através de saídas residenciais, e os bytes reais por resposta depois que sua estratégia de coleta estiver definida. Ambas são fáceis de medir em uma execução pequena, e ambas alteram materialmente o plano.

Execute um piloto com talvez cinco por cento do volume pretendido, registre a taxa de sucesso validada, os percentis de latência e os bytes por requisição por alvo, e depois recalcule. Espere que a resposta difira da sua estimativa em ambas as direções. O método de medição está em testando velocidade, taxa de sucesso e precisão de localização, e as versões contínuas desses mesmos números são as métricas em KPIs de proxy.

Um resumo prático

Requisito: 50.000 registros diariamente, prontos até as 08:00, janela de coleta das 04:00 às 08:00.

1,2 requisições por registro, resultando em 60.000 sucessos. Com 90% de taxa de sucesso validada, cerca de 67.000 tentativas. Em quatro horas, isso é 4,7 por segundo. Com dois segundos de latência média, aproximadamente 10 requisições simultâneas em andamento, que você então divide entre os alvos em vez de direcionar a um só. Com 80 KB em média por resposta, cerca de 5,4 GB por execução e aproximadamente 160 GB por mês. Adicione margem tanto na concorrência quanto na largura de banda, porque a latência oscila e as taxas de sucesso caem, e recalcule após o piloto.

Resumo final

Planeje de trás para frente: registros para requisições, requisições para tentativas após margem de falha, tentativas na janela para uma taxa, taxa vezes latência para concorrência, e tentativas vezes tamanho de resposta para largura de banda. Limite a concorrência e a taxa por alvo, em vez de globalmente, porque a restrição vinculante é o que cada site tolera, e não o que sua infraestrutura consegue produzir. Otimize o que você busca antes de dimensionar o plano, já que renderizar versus buscar dados pode alterar a resposta de largura de banda em duas ordens de grandeza. Espalhe o trabalho pela janela disponível em vez de concentrá-lo em rajadas. Depois execute um piloto, porque latência e bytes por resposta são as duas suposições que vale a pena substituir por medições antes de se comprometer com um plano.

A capacidade em si vem dos proxies residenciais, onde a concorrência não é a restrição sobre a qual o plano é dimensionado, com preços por GB para que o valor de largura de banda que você deriva seja o número que você realmente está comprando.