שלושה מרווחי המתנה עבור שלושה APIs

בניתי צינורות ETL עבור שלושה אתרי ספריות באפריל. כל אתר משתמש ב-API שונה: Steam, GitHub, ו-HuggingFace.

הייתי צריך להגדיר מרווחי המתנה (sleep intervals) עבור כל אחד מהם. המספרים, מצבי הכישלון וטיפול בשגיאות הם כולם שונים. הנה מה שאני משתמש בו ומדוע.

Steam: המתנה של 250ms

התיעוד של Steam מעורפל לגבי מגבלות קצב (rate limits). נתונים מהקהילה מצביעים על בערך 200 בקשות כל 5 דקות לכל כתובת IP. זה אומר שמרווח של 1.5 שניות הוא בטוח.

אני משתמש ב-250ms במקום זאת. התהליך הלילי שלי מעבד רק 60 רשומות של משחקים. ב-250ms, זמן ההמתנה הכולל הוא 15 שניות. ב-1.5 שניות, הוא הופך ל-90 שניות. חיסכון בזמן חשוב כשמעבדים מספר אתרים.

אם Steam מחזיר שגיאה, התהליך לא עוצר. הוא מתעד את השגיאה וממשיך לפריט הבא. הנתונים מתעדכנים בלילה הבא.

GitHub: המתנה של 100ms

GitHub מאוד ברור. למשתמשים ללא אימות (unauthenticated) מוקצות 60 בקשות בשעה. למשתמשים עם token מוקצות 5,000 בקשות בשעה.

אני משתמש בהמתנה של 100ms כצעד של "נימוס". ה-token עושה את העבודה הקשה בנוגע למגבלת הקצב. ה-pipeline שלי משתמש ב-core REST API, ולא ב-search API. זה מאפשר מגבלות גבוהות הרבה יותר.

HuggingFace: ללא המתנה

לא נתקלתי במגבלת קצב במשך שבועות של הרצות ליליות. ה-registry API תוכנן עבור כלי batch כמו שלי.

אני שולף עד 100 מודלים בבת אחת. אני משתמש ב-authentication token כדי להעלות את המגבלות אף יותר. עבור 100 מודלים, פתרון ללא המתנה הוא הפשוט ביותר.

טבלת סיכום:

• Steam: המתנה של 250ms. שגיאות לא קטלניות. • GitHub: המתנה של 100ms. שגיאות לא קטלניות. • HuggingFace: ללא המתנה. שגיאות לא קטלניות.

מרווח ההמתנה הוא ניחוש. ההגנה האמיתית היא האופן שבו אני מטפל בשגיאות. כל קריאת API משתמשת בבלוק try/catch. אם קריאה נכשלת, המערכת כותבת שורת fallback במקום לקרוס.

מרווח ההמתנה שולט על התדירות שבה אתם מגיעים למגבלה. הטיפול בשגיאות שולט על מה שקורה כשאתם מגיעים אליה.

מקור: https://dev.to/morinaga/three-sleep-intervals-for-three-apis-steam-250ms-github-100ms-huggingface-none-4ga7

קהילת למידה אופציונלית: https://t.me/GyaanSetuAi