Três Intervalos de Sleep para Três APIs
Eu construí pipelines de ETL para três sites de diretórios em abril. Cada site utiliza uma API diferente: Steam, GitHub e HuggingFace.
Tive que definir intervalos de sleep para cada uma delas. Os números, os modos de falha e o tratamento de erros são todos diferentes. Aqui está o que eu utilizo e o porquê.
Steam: 250ms de sleep
A documentação da Steam é vaga sobre limites de taxa (rate limits). Dados da comunidade sugerem aproximadamente 200 requisições a cada 5 minutos por IP. Isso significa que um intervalo de 1,5 segundo é seguro.
Eu utilizo 250ms em vez disso. Meu job noturno processa apenas 60 entradas de jogos. Com 250ms, o tempo total de sleep é de 15 segundos. Com 1,5 segundo, torna-se 90 segundos. Economizar tempo é importante quando você processa múltiplos sites.
Se a Steam retornar um erro, o job não para. Ele registra o erro e passa para o próximo item. Os dados são atualizados na noite seguinte.
GitHub: 100ms de sleep
O GitHub é muito claro. Usuários não autenticados recebem 60 requisições por hora. Usuários com um token recebem 5.000 requisições por hora.
Eu utilizo um sleep de 100ms como uma medida de cortesia. O token faz o trabalho pesado em relação ao limite de taxa. Meu pipeline utiliza a REST API principal, não a search API. Isso permite limites muito mais altos.
HuggingFace: Sem sleep
Não atingi um limite de taxa em semanas de execuções noturnas. A registry API foi projetada para ferramentas de lote (batch) como a minha.
Eu busco até 100 modelos de uma só vez. Utilizo um token de autenticação para elevar ainda mais os limites. Para 100 modelos, não usar sleep é a solução mais simples.
Tabela de Resumo:
• Steam: 250ms de sleep. Erros não fatais. • GitHub: 100ms de sleep. Erros não fatais. • HuggingFace: Sem sleep. Erros não fatais.
O intervalo de sleep é uma estimativa. A proteção real é como eu trato os erros. Cada chamada de API utiliza um bloco try/catch. Se uma chamada falha, o sistema escreve uma linha de fallback em vez de travar.
O intervalo de sleep controla a frequência com que você atinge um limite. O tratamento de erros controla o que acontece quando você o atinge.
Comunidade de aprendizado opcional: https://t.me/GyaanSetuAi