Como configurar a concorrência de raspagem de web sem tempestades de retries

TL;DR

• Limites de concorrência limitam o trabalho em andamento; limites de taxa controlam a velocidade com que novas solicitações começam.
• Aplicar limites ao escopo da fonte e da conta que realmente compartilham capacidade, não apenas a cada trabalhador individualmente.
• Solicitações repetidas devem consumir o mesmo orçamento de admissão que os primeiros tentativas.
• Trate o HTTP 429 como um sinal de cooldown compartilhado e preservar qualquer instrução válida de Retry-After.
• Aumente a concorrência apenas enquanto a taxa de dados aceitos melhora sem latência inaceitável, erros ou crescimento da fila.
• Mantenha tarefas de CAPTCHA e solicitações de destino em piscinas separadas com uma transferência explícita entre elas.

Um raspador pode lançar mais solicitações e coletar menos dados úteis. Respostas lentas mantêm conexões ocupadas, trabalhadores repetem solicitações falhas e a fila enche-se de cópias do trabalho já em andamento. Aumentar o número de trabalhadores pode então amplificar o mesmo gargalo. A medida de desempenho útil é os dados aceitos entregues dentro do prazo da tarefa, não o número de solicitações iniciadas.

Este guia explica como definir um limite de concorrência para um fluxo de trabalho de coleta autorizado. Ele abrange admissão no nível da fonte, agendamento de repetições, capacidade do navegador e um processo de ajuste controlado. CapSolver se encaixa em uma etapa separada de tarefas de CAPTCHA quando o fluxo permitido requer uma. Nem um maior grupo de trabalhadores nem um desafio concluído altera a política de taxa da fonte, então o agendador deve manter o controle durante toda a execução.

Separe a concorrência da taxa de solicitação

Concorrência é o número de operações atualmente em andamento, enquanto a taxa de solicitação mede os inícios ao longo do tempo. Um limite de concorrência sozinho não garante uma taxa de início estável, pois a resposta muda a velocidade com que os slots ficam disponíveis.

Imagine uma fonte testada com quatro slots de solicitação ativos. Se as solicitações terminarem rapidamente, esses slots podem gerar muitos inícios em um curto período. Se as respostas forem lentas, os mesmos quatro slots geram menos inícios, mas passam mais tempo ocupados. Ambos os comportamentos obedecem ao limite de concorrência. Um controlador de taxa separado é necessário quando os inícios devem permanecer dentro de uma cota baseada no tempo.

O glossário de concorrência e o glossário de limitação de taxa descrevem conceitos relacionados. No seu agendador, registre-os como configurações separadas. Adicione uma fila máxima e um prazo da tarefa para que o trabalho atrasado não se acumule indefinidamente atrás de limites razoáveis.

Não há um número universal ideal de solicitações concorrentes. A política da fonte, o tamanho da carga útil, o renderização do navegador, a largura de banda e o processamento posterior todos influenciam o ponto operacional útil. Comece com a cota documentada da fonte e sua própria capacidade, depois meça uma carga de trabalho explicitamente permitida.

Etapa 1: Defina o escopo que compartilha um limite

Um limite de concorrência deve abranger os trabalhadores que competem pela mesma capacidade ou permissão. Uma configuração por processo é insuficiente quando vários processos, máquinas ou tarefas acessam a mesma fonte limitada.

Identifique o escopo relevante antes de criar trabalhadores. Pode ser um hostname, uma credencial de API, uma cota de conta definida pela fonte ou uma sessão de navegador controlada. Use o escopo descrito pelo provedor em vez de assumir que cada URL tem capacidade independente. Subdomínios também podem compartilhar infraestrutura ou cota de conta.

Separe a capacidade global da capacidade da fonte. Um teto global protege suas próprias máquinas e recursos de saída. Teto por fonte evita que uma fila rápida consuma todos os slots disponíveis. Se a fonte estiver temporariamente pausada, outra fonte independentemente permitida pode continuar sem usar a identidade ou cota da fonte pausada.

Para fluxos de navegador, decida o que ocupa um slot: uma navegação, uma página ativa ou uma sessão inteira. Uma sessão vinculada à conta não deve ser compartilhada casualmente entre tarefas concorrentes. Seus cookies, ações pendentes e destino esperado precisam de um proprietário durante a duração da tarefa.

Etapa 2: Faça com que cada solicitação passe pela admissão

A admissão deve ocorrer antes da solicitação começar e deve ser aplicada igualmente a tentativas iniciais, repetições, redirecionamentos controlados pelo seu cliente e reinícios de trabalhadores. Um caminho de repetição que envia diretamente para o transporte pode anular os limites do agendador principal.

Use uma identidade de tarefa para a observação desejada e identidades de tentativa separadas para o trabalho de transporte. Isso permite que a fila distinga uma repetição legítima de uma tarefa programada duplicada. Se um trabalhador reiniciar, ele deve verificar se a observação já foi concluída antes de criar outra solicitação.

Um slot deve ser liberado quando a operação relevante realmente terminou ou seu transporte foi cancelado. Liberar a capacidade apenas porque o chamador parou de esperar pode deixar solicitações ocultas rodando além do limite nominal. Trate o trabalho incerto ou ainda em execução como capacidade ocupada até que seu estado seja resolvido.

Limite também a fila. Quando muito trabalho chega, adie uma janela de coleta posterior, rejeite a demanda excedente ou reduza o escopo solicitado de acordo com seu contrato de serviço. Manter uma fila ilimitada transfere falhas para pressão de memória e observações obsoletas.

Etapa 3: Agende repetições em vez de dormir em todos os lugares

As repetições devem retornar a uma fila controlada com um horário futuro, um número de tentativas e o prazo restante da tarefa. Chamadas de dormir dispersas dentro dos trabalhadores dificultam a coordenação de um cooldown compartilhado.

O status HTTP 429 indica que muitas solicitações foram enviadas dentro de um período relevante. Quando a resposta inclui Retry-After, preservar seu atraso ou semântica de data. Não deixe que cada trabalhador escolha independentemente um tempo de espera mais curto.

Use um cooldown compartilhado para o escopo afetado. Pare de admitir novos trabalhos lá enquanto o cooldown estiver ativo, incluindo solicitações que nunca falharam. O trabalho já em execução pode terminar, mas uma resposta bem-sucedida de um trabalhador não deve automaticamente apagar um cooldown válido observado por outro.

Para falhas temporárias de leitura sem orientação explícita do servidor, aplique uma política de repetição limitada adequada à operação. Um horário estendido pode evitar explosões sincronizadas após a pausa. Não adicione repetições a um envio de formulário ou outra operação que mude o estado, a menos que seu efeito e repetibilidade sejam compreendidos.

Observação	Resposta do agendador	Evidência a manter
HTTP 429	Pausar o escopo afetado e respeitar a orientação de repetição	Escopo da fonte, tempo de resposta, cooldown
Tempo limite de leitura temporário	Reenfileirar apenas dentro do orçamento de tentativa e prazo	Identidade de tentativa e tempo restante
Autenticação ou recusa de acesso	Parar ou redirecionar para revisão de acesso	Categoria de resposta redigida
Ponto de verificação de CAPTCHA suportado	Entrar em uma etapa separada de desafio permitido	Observação atual e contexto de desafio
Registro extraído inválido	Investigar análise ou dados da fonte	Referência de página retida e erro de validação

Resgate seu código de bônus do CapSolver

Aumente seu orçamento de automação instantaneamente!
Use o código de bônus CAP26 ao recarregar sua conta do CapSolver para obter um bônus adicional de 5% em cada recarga — sem limites.
Resgate-o agora em seu Painel do CapSolver

Etapa 4: Mantenha o tratamento de desafios longe de multiplicar a demanda

Um ponto de verificação de CAPTCHA deve criar uma transferência controlada, não um loop adicional de solicitações ao lado do raspador. A observação de destino permanece uma tarefa mesmo que exija uma etapa de desafio suportada.

A documentação createTask do CapSolver define a submissão de tarefa, enquanto getTaskResult documenta a recuperação de resultados. Siga os requisitos de tarefa aplicáveis e mantenha a identidade da tarefa retornada associada à observação atual. Polpear uma tarefa conhecida e criar uma nova tarefa são operações diferentes.

Dê a essa etapa seu próprio limite para trabalho ativo, tempo e tentativas. A cota de taxa da fonte ainda se aplica quando o navegador retoma. Um resultado de desafio não deve conceder uma exceção imediata a um cooldown da fonte ou causar todos os trabalhadores pausados a reiniciarem juntos.

Se a submissão de tarefa expirar antes de sua aceitação ser conhecida, mantenha a incerteza. Submeter cegamente outra tarefa pode duplicar o trabalho. O agendador deve saber se está esperando por um resultado existente, investigando uma solicitação incerta ou fechando a observação para revisão.

Após a continuação da destino, verifique a página esperada e registre o contrato. Caso contrário, o aumento do throughput de desafio pode ocultar o fato de que a saída de coleta aceita não melhorou.

Etapa 5: Execute um aumento controlado de concorrência

Um aumento de concorrência deve alterar um único ajuste de capacidade, mantendo o trabalho de comparação e os critérios de aceitação estáveis. Use uma fonte de teste própria ou outro ambiente onde o teste de carga seja explicitamente permitido.

Estabeleça uma base

Comece com uma carga de trabalho pequena permitida e registre observações concluídas, registros aceitos, latência de solicitação, categorias de erro e idade da fila. Separe o tempo gasto esperando por admissão do tempo gasto na rede ou no navegador. Uma duração total longa pode ter causas diferentes que exigem soluções diferentes.

Mantenha as primeiras tentativas e repetições visíveis no mesmo relatório. Se os registros aceitos permanecerem constantes enquanto o número total de solicitações aumentar, o tráfego adicional não está produzindo throughput útil. Verifique se a política de repetição, prontidão da página ou validação posterior explica a diferença antes de adicionar trabalhadores.

Aumente apenas enquanto o resultado melhorar

Aumente o limite em um passo pré-definido modesto e observe um intervalo comparável. Parem de aumentar quando o throughput aceito se estabilizar, a frequência de falhas aumentar ou a latência de cauda exceder as necessidades da tarefa. Essas observações identificam um limite de capacidade para esse trabalho; não provam um limite permanente em toda a plataforma.

Repita casos representativos com tamanhos de carga útil e tipos de página diferentes. Uma página HTML leve e um painel com JavaScript pesado podem exigir recursos de navegador muito diferentes. Evite selecionar o limite de operação apenas com as páginas mais fáceis.

Mantenha espaço para variação

Escolha um ponto de operação com espaço abaixo do limite de falha em vez de executar permanentemente no valor mais alto que passou brevemente. O desempenho da fonte e sua própria infraestrutura podem variar. Reserve capacidade para trabalho programado e evite que trabalhos exploratórios tomem todo o pool.

Entenda quais controles de throttling automático

O throttling automático pode adaptar o tempo de solicitação ao latência observada, mas seu comportamento depende da implementação e dos limites configurados. Leia a documentação do framework consumidor antes de combiná-lo com um segundo agendador.

A documentação Scrapy AutoThrottle descreve uma concorrência alvo e ajuste de atraso baseado em latência, respeitando os tetos de concorrência configurados. Seu objetivo não é uma promessa incondicional de que um número exato de solicitações sempre estará ativo. Respostas não bem-sucedidas também recebem tratamento especial no cálculo do atraso.

Use controles específicos do framework para seu escopo documentado. Um throttle local de um raspador não coordena automaticamente implantações separadas ou impõe uma cota organizacional total. Se vários trabalhos compartilham uma cota, coloque um controlador compartilhado acima desses trabalhadores independentes.

Registre a configuração efetiva usada para cada execução. Um experimento de concorrência é difícil de reproduzir se o framework, o grupo de transporte, o middleware de repetição e o agendador externo mudarem ao mesmo tempo. A visão geral da infraestrutura de navegador fornece contexto útil para separar esses recursos.

Diagnose throughput mais baixo antes de aumentar capacidade

Um throughput aceito mais baixo pode vir da rede, fonte, navegador, parser ou armazenamento de destino. Mais trabalhadores de busca só ajudam alguns desses gargalos e podem piorar outros.

Se a fila crescer enquanto os slots de rede permanecerem ociosos, inspecione a lógica de admissão e cooldown. Se a memória do navegador aumentar, revise a duração da sessão e a limpeza de páginas. Se as solicitações terminarem, mas os registros forem rejeitados, inspecione a prontidão do conteúdo, mudanças de esquema e comportamento do parser. Se os registros aceitos esperarem para serem armazenados, aplique pressão de volta do escritor de baixo nível.

Mantenha um procedimento de pausa explícito. Os operadores devem ser capazes de parar novos inícios para uma fonte, preservar identidades de tarefa em andamento e retomar gradualmente após o problema ser compreendido. Reiniciar todos os trabalhadores de uma vez é uma substituição pobre para uma reabertura controlada de capacidade.

Ajuste para saída de coleta útil

Defina a concorrência de raspagem com base na política da fonte, propriedade real de recursos e registros aceitos. Roteie cada tentativa através da admissão, coordene cooldowns e aumente a carga apenas quando a pipeline completa se beneficia.

Para fluxos que exigem tratamento de CAPTCHA suportado, use CapSolver em uma etapa separada limitada e retorne aos mesmos controles da fonte depois. Um agendador disciplinado torna o sistema mais fácil de operar à medida que a carga e o comportamento da página mudam.

Perguntas frequentes

Q: Um limite de concorrência é o mesmo que um limite de solicitações por segundo?

Não. Limites de concorrência limitam operações ativas. Limites de taxa controlam os inícios ao longo do tempo, então você pode precisar de ambos os controles.

Q: Cada trabalhador deve lidar com HTTP 429 independentemente?

Trabalhadores que compartilham o mesmo escopo limitado de taxa devem coordenar seu cooldown. Repetições independentes podem recriar uma explosão mesmo quando cada trabalhador parece conservador.

Q: Posso resolver a raspagem lenta aumentando a concorrência?

Apenas quando a capacidade adicional melhorar a saída aceita dentro dos limites permitidos da fonte. Primeiro identifique se a aquisição, renderização, análise ou armazenamento é o gargalo.

Q: Um resultado de CAPTCHA deve permitir que uma solicitação pule o agendador?

Não. As regras de taxa e concorrência da destino ainda se aplicam após o tratamento do desafio.

Q: O que deve acontecer quando o armazenamento de baixo nível ficar para trás?

Reduza ou pause a nova aquisição por meio de pressão de volta. Uma fila ilimitada de páginas recuperadas aumenta o uso de recursos e pode deixar observações obsoletas antes de serem aceitas.