Three Sleep Intervals for Three APIs
W kwietniu zbudowałem potoki ETL dla trzech serwisów katalogowych. Każdy z nich korzysta z innego API: Steam, GitHub i HuggingFace.
Musiałem ustawić interwały uśpienia dla każdego z nich. Liczby, tryby awarii i obsługa błędów różnią się od siebie. Oto co stosuję i dlaczego.
Steam: 250 ms uśpienia
Dokumentacja Steam jest niejasna w kwestii limitów zapytań (rate limits). Dane społeczności sugerują około 200 żądań co 5 minut na jeden adres IP. Oznacza to, że 1,5-sekundowy interwał jest bezpieczny.
Zamiast tego stosuję 250 ms. Moje nocne zadanie przetwarza tylko 60 wpisów dotyczących gier. Przy 250 ms całkowity czas uśpienia wynosi 15 sekund. Przy 1,5 sekundy wzrasta on do 90 sekund. Oszczędność czasu ma znaczenie, gdy przetwarzasz wiele serwisów.
Jeśli Steam zwróci błąd, zadanie nie zostaje przerwane. Błąd jest logowany, a system przechodzi do kolejnego elementu. Dane są aktualizowane następnej nocy.
GitHub: 100 ms uśpienia
GitHub jest bardzo jasny. Nieautoryzowani użytkownicy mają 60 żądań na godzinę. Użytkownicy z tokenem mają 5000 żądań na godzinę.
Stosuję 100 ms uśpienia jako wyraz uprzejmości. To token wykonuje „ciężką pracę” w kontekście limitów zapytań. Mój potok wykorzystuje podstawowe REST API, a nie search API. Pozwala to na znacznie wyższe limity.
HuggingFace: Brak uśpienia
Od tygodni nocnych uruchomień nie napotkałem limitu zapytań. API