তিনটি API-এর জন্য তিনটি স্লিপ ইন্টারভাল

আমি এপ্রিলে তিনটি ডিরেক্টরি সাইটের জন্য ETL পাইপলাইন তৈরি করেছি। প্রতিটি সাইট আলাদা আলাদা API ব্যবহার করে: Steam, GitHub, এবং HuggingFace।

আমাকে প্রতিটি সাইটের জন্য স্লিপ ইন্টারভাল সেট করতে হয়েছিল। সংখ্যা, ফেইলিওর মোড (failure modes) এবং এরর হ্যান্ডলিং—সবই আলাদা। আমি কী ব্যবহার করি এবং কেন, তা নিচে দেওয়া হলো।

Steam: 250ms স্লিপ

Steam-এর ডকুমেন্টেশনে রেট লিমিট (rate limits) সম্পর্কে অস্পষ্ট তথ্য দেওয়া আছে। কমিউনিটির তথ্য অনুযায়ী, প্রতি আইপি (IP) থেকে প্রতি ৫ মিনিটে প্রায় ২০০টি রিকোয়েস্ট করা সম্ভব। এর মানে হলো ১.৫ সেকেন্ডের ইন্টারভাল নিরাপদ।

পরিবর্তে আমি ২৫০ms ব্যবহার করি। আমার নাইটলি জব (nightly job) মাত্র ৬০টি গেম এন্ট্রি প্রসেস করে। ২৫০ms ব্যবহার করলে মোট স্লিপ টাইম হয় ১৫ সেকেন্ড। আর ১.৫ সেকেন্ড হলে তা হয়ে যায় ৯০ সেকেন্ড। যখন আপনি একাধিক সাইট প্রসেস করেন, তখন সময় বাঁচানো গুরুত্বপূর্ণ।

যদি Steam কোনো এরর (error) প্রদান করে, তবে জবটি থেমে যায় না। এটি এররটি লগ (log) করে এবং পরবর্তী আইটেমে চলে যায়। ডেটা পরের রাতে আপডেট করা হয়।

GitHub: 100ms স্লিপ

GitHub খুবই স্পষ্ট। অথেন্টিকেটেড নয় এমন ব্যবহারকারীরা প্রতি ঘণ্টায় ৬০টি রিকোয়েস্ট পায়। টোকেন ব্যবহারকারী ব্যবহারকারীরা প্রতি ঘণ্টায় ৫,০০০টি রিকোয়েস্ট পায়।

আমি সৌজন্যমূলক পদক্ষেপ হিসেবে ১০০ms স্লিপ ব্যবহার করি। রেট লিমিটের ক্ষেত্রে টোকেনটি মূল কাজ করে দেয়। আমার পাইপলাইনটি কোর REST API ব্যবহার করে, সার্চ API নয়। এর ফলে অনেক বেশি লিমিট পাওয়া সম্ভব হয়।

HuggingFace: কোনো স্লিপ নেই

কয়েক সপ্তাহ ধরে নাইটলি রান করার পরও আমি কোনো রেট লিমিটে পড়িনি। এর রেজিস্ট্রি API আমার মতো ব্যাচ টুলের (batch tools) জন্যই ডিজাইন করা হয়েছে।

আমি একবারে ১০০টি মডেল পর্যন্ত ফেচ (fetch) করি। লিমিট আরও বাড়ানোর জন্য আমি একটি অথেন্টিকেশন টোকেন ব্যবহার করি। ১০০টি মডেলের জন্য কোনো স্লিপ না রাখাই সবচেয়ে সহজ সমাধান।

সারসংক্ষেপ টেবিল:

• Steam: 250ms স্লিপ। নন-ফ্যাটাল এরর (Non-fatal errors)। • GitHub: 100ms স্লিপ। নন-ফ্যাটাল এরর। • HuggingFace: কোনো স্লিপ নেই। নন-ফ্যাটাল এরর।

স্লিপ ইন্টারভাল একটি অনুমান মাত্র। আসল সুরক্ষা হলো আমি কীভাবে এরর হ্যান্ডেল করি। প্রতিটি API কলের জন্য একটি try/catch ব্লক ব্যবহার করা হয়। যদি কোনো কল ব্যর্থ হয়, সিস্টেমটি ক্র্যাশ করার পরিবর্তে একটি ফলব্যাক রো (fallback row) লিখে রাখে।

স্লিপ ইন্টারভাল নিয়ন্ত্রণ করে আপনি কত ঘন ঘন লিমিটে পৌঁছাচ্ছেন। আর এরর হ্যান্ডলিং নিয়ন্ত্রণ করে লিমিটে পৌঁছালে কী ঘটবে।

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

ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi