మూడు APIల కోసం మూడు స్లీప్ ఇంటర్వల్స్

నేను ఏప్రిల్‌లో మూడు డైరెక్టరీ సైట్‌ల కోసం ETL పైప్‌లైన్‌లను రూపొందించాను. ప్రతి సైట్ వేర్వేరు APIలను ఉపయోగిస్తుంది: Steam, GitHub, మరియు HuggingFace.

నేను ప్రతి దాని కోసం స్లీప్ ఇంటర్వల్స్‌ను సెట్ చేయాల్సి వచ్చింది. వాటి సంఖ్యలు, ఫెయిల్యూర్ మోడ్స్ మరియు ఎర్రర్ హ్యాండ్లింగ్ అన్నీ వేర్వేరుగా ఉన్నాయి. నేను దేనిని ఎందుకు ఉపయోగిస్తున్నానో ఇక్కడ చూడండి.

Steam: 250ms స్లీప్

రేట్ లిమిట్స్ (rate limits) గురించి Steam డాక్యుమెంటేషన్ స్పష్టంగా లేదు. కమ్యూనిటీ డేటా ప్రకారం, ప్రతి IPకి ప్రతి 5 నిమిషాలకు సుమారు 200 రిక్వెస్ట్‌లు అనుమతించబడతాయి. అంటే 1.5 సెకన్ల ఇంటర్వల్ సురక్షితం.

దానికి బదులుగా నేను 250ms ఉపయోగిస్తున్నాను. నా నైట్లీ జాబ్ (nightly job) కేవలం 60 గేమ్ ఎంట్రీలను మాత్రమే ప్రాసెస్ చేస్తుంది. 250ms వద్ద, మొత్తం స్లీప్ సమయం 15 సెకన్లు. 1.5 సెకన్ల వద్ద, అది 90 సెకన్లకు చేరుతుంది. మీరు బహుళ సైట్‌లను ప్రాసెస్ చేస్తున్నప్పుడు సమయాన్ని ఆదా చేయడం ముఖ్యం.

ఒకవేళ Steam ఎర్రర్‌ను రిటర్న్ చేస్తే, జాబ్ ఆగిపోదు. అది ఎర్రర్‌ను లాగ్ (log) చేసి తదుపరి ఐటెమ్‌కు వెళ్తుంది. డేటా మరుసటి రాత్రి అప్‌డేట్ చేయబడుతుంది.

GitHub: 100ms స్లీప్

GitHub చాలా స్పష్టంగా ఉంది. అథెంటికేట్ కాని (Unauthenticated) వినియోగదారులకు గంటకు 60 రిక్వెస్ట్‌లు లభిస్తాయి. టోకెన్ ఉన్న వినియోగదారులకు గంటకు 5,000 రిక్వెస్ట్‌లు లభిస్తాయి.

నేను మర్యాదపూర్వక చర్యగా (politeness measure) 100ms స్లీప్‌ను ఉపయోగిస్తున్నాను. రేట్ లిమిట్ విషయంలో టోకెన్ ప్రధాన పాత్ర పోషిస్తుంది. నా పైప్‌లైన్ కోర్ REST APIని ఉపయోగిస్తుంది, సెర్చ్ APIని కాదు. ఇది చాలా ఎక్కువ లిమిట్‌లను అనుమతిస్తుంది.

HuggingFace: No sleep

వారాల తరబడి నైట్లీ రన్‌లలో నేను ఎప్పుడూ రేట్ లిమిట్‌ను చేరుకోలేదు. రిజిస్ట్రీ API నా వంటి బ్యాచ్ టూల్స్ కోసం రూపొందించబడింది.

నేను ఒకేసారి 100 మోడల్స్ వరకు ఫెచ్ (fetch) చేస్తాను. లిమిట్‌లను ఇంకా పెంచడానికి నేను అథెంటికేషన్ టోకెన్‌ను ఉపయోగిస్తాను. 100 మోడల్స్ కోసం, స్లీప్ లేకుండా ఉండటమే అత్యంత సరళమైన పరిష్కారం.

Summary Table:

• Steam: 250ms స్లీప్. నాన్-ఫేటల్ ఎర్రర్స్ (Non-fatal errors). • GitHub: 100ms స్లీప్. నాన్-ఫేటల్ ఎర్రర్స్ (Non-fatal errors). • HuggingFace: No sleep. నాన్-ఫేటల్ ఎర్రర్స్ (Non-fatal errors).

స్లీప్ ఇంటర్వల్ అనేది ఒక అంచనా మాత్రమే. అసలైన రక్షణ నేను ఎర్రర్లను ఎలా హ్యాండిల్ చేస్తాననే దానిపై ఆధారపడి ఉంటుంది. ప్రతి API కాల్ try/catch బ్లాక్‌ను ఉపయోగిస్తుంది. ఒక కాల్ విఫలమైతే, సిస్టమ్ క్రాష్ అవ్వడానికి బదులుగా ఫాల్‌బ్యాక్ రో (fallback row)ను రాస్తుంది.

స్లీప్ ఇంటర్వల్ మీరు ఎంత తరచుగా లిమిట్‌ను చేరుకుంటారో నియంత్రిస్తుంది. ఎర్రర్ హ్యాండ్లింగ్ మీరు లిమిట్‌ను చేరుకున్నప్పుడు ఏం జరుగుతుందో నియంత్రిస్తుంది.

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

Optional learning community: https://t.me/GyaanSetuAi