Google Play EMM API-এর প্রতিটি EMM-এর জন্য প্রতি মিনিটে 60,000 প্রশ্নের ডিফল্ট সীমা রয়েছে।
আপনি যদি কোটা অতিক্রম করেন, তাহলে Google Play EMM API HTTP 429 Too Many Requests প্রদান করে। আপনি উল্লিখিত ব্যবহারের সীমা অতিক্রম করবেন না তা নিশ্চিত করতে এবং আপনার ব্যবহারকারীদের জন্য একটি সর্বোত্তম অভিজ্ঞতা অফার করতে সাহায্য করার জন্য, নীচের বিভাগে বর্ণিত কিছু সেরা অনুশীলনের বাস্তবায়ন বিবেচনা করুন।
API ব্যবহারের সীমার নিচে থাকার জন্য সুপারিশ
Google Play EMM API ব্যবহার করার সময়, কিছু সর্বোত্তম অনুশীলন রয়েছে যা আপনি অনুরোধগুলি বিতরণ করতে এবং ব্যবহারের সীমা অতিক্রম করার ঝুঁকি কমাতে প্রয়োগ করতে পারেন৷
শুরুর সময় এবং ব্যবধান র্যান্ডমাইজ করুন
একই সময়ে ডিভাইসগুলি সিঙ্ক করা বা চেক-ইন করার মতো ক্রিয়াকলাপগুলির ফলে অনুরোধের পরিমাণ উল্লেখযোগ্যভাবে বৃদ্ধি পেতে পারে৷ নিয়মিত নির্ধারিত ব্যবধানে এই ক্রিয়াকলাপগুলি সম্পাদন করার পরিবর্তে, আপনি এই বিরতিগুলিকে এলোমেলো করে আপনার অনুরোধের লোড বিতরণ করতে পারেন। উদাহরণস্বরূপ, প্রতি 24 ঘন্টা প্রতিটি ডিভাইস সিঙ্ক করার পরিবর্তে, আপনি 23 থেকে 25 ঘন্টার মধ্যে একটি এলোমেলোভাবে নির্বাচিত সময়ের মধ্যে প্রতিটি ডিভাইস সিঙ্ক করতে পারেন৷ এটি অনুরোধের সংখ্যা ছড়িয়ে দিতে সাহায্য করে।
একইভাবে, আপনি যদি একটি দৈনিক কাজ চালান যা দ্রুত উত্তরাধিকারসূত্রে অনেকগুলি API কল করে, তবে একই সময়ে আপনার সমস্ত এন্টারপ্রাইজ গ্রাহকদের জন্য উচ্চ পরিমাণে অনুরোধ করা প্রতিরোধ করতে প্রতিদিন একটি এলোমেলো সময়ে কাজ শুরু করার কথা বিবেচনা করুন।
অনুরোধ পুনরায় চেষ্টা করতে সূচকীয় ব্যাকঅফ ব্যবহার করুন
আপনি যদি অনেকগুলি API কল সমন্বিত কাজগুলি চালান, তাহলে কোটায় পৌঁছানোর প্রতিক্রিয়া হিসাবে একটি সূচকীয় ব্যাকঅফ কৌশল ব্যবহার করুন৷ এক্সপোনেনশিয়াল ব্যাকঅফ হল একটি অ্যালগরিদম যা অনুরোধগুলিকে দ্রুতগতিতে পুনরায় চেষ্টা করে৷ সাধারণ সূচকীয় ব্যাকঅফ বাস্তবায়নের জন্য একটি উদাহরণ প্রবাহ নিম্নরূপ:
- Google Play EMM API এ একটি অনুরোধ করুন৷
- একটি
HTTP 429প্রতিক্রিয়া পান৷ - 2 সেকেন্ড +
random_timeঅপেক্ষা করুন, তারপর অনুরোধটি আবার চেষ্টা করুন। - একটি
HTTP 429প্রতিক্রিয়া পান৷ - 4 সেকেন্ড +
random_timeঅপেক্ষা করুন, তারপর অনুরোধটি আবার চেষ্টা করুন। - একটি
HTTP 429প্রতিক্রিয়া পান৷ - 8 সেকেন্ড +
random_timeঅপেক্ষা করুন, তারপর অনুরোধটি আবার চেষ্টা করুন।
random_time সাধারণত -0.5 * অপেক্ষার সময় থেকে +0.5 * অপেক্ষার সময় পর্যন্ত একটি এলোমেলো সংখ্যা। প্রতিবার যখন আপনি আপনার অনুরোধ পুনরায় চেষ্টা করবেন তখন একটি নতুন random_time পুনরায় সংজ্ঞায়িত করুন। ব্যবহারকারী-মুখী ক্রিয়াগুলি সম্পূর্ণ করার জন্য প্রয়োজনীয় API কলগুলি আরও ঘন ঘন সময়সূচীতে পুনরায় চেষ্টা করা যেতে পারে (উদাহরণস্বরূপ 0.5s, 1s এবং 2s)।
হার-সীমা ব্যাচ প্রক্রিয়া
প্রতিবার একটি ব্যাচড প্রক্রিয়া কোটায় পৌঁছালে, API কল করে এমন ব্যবহারকারীর ক্রিয়াকলাপের লেটেন্সি বেড়ে যায়। এই ধরনের পরিস্থিতিতে, ব্যবহারকারীর ক্রিয়াকলাপের জন্য কম বিলম্ব বজায় রাখার জন্য সূচকীয় ব্যাকঅফের মতো কৌশলগুলি যথেষ্ট কার্যকর নাও হতে পারে।
বারবার API-এর ব্যবহার সীমাতে না পৌঁছাতে এবং ব্যবহারকারী-মুখী ক্রিয়াকলাপের জন্য লেটেন্সি বাড়ানো এড়াতে, আপনার ব্যাচ করা প্রক্রিয়াগুলির জন্য একটি রেট লিমিটার ব্যবহার করার কথা বিবেচনা করুন ( Google এর RateLimiter দেখুন)। একটি রেট লিমিটার দিয়ে আপনি আপনার API অনুরোধের হার সামঞ্জস্য করতে পারেন যাতে আপনি ধারাবাহিকভাবে ব্যবহারের সীমার নিচে থাকেন।
উদাহরণস্বরূপ, 50 QPS এর ডিফল্ট হার সীমা সহ একটি ব্যাচড প্রক্রিয়া শুরু করুন। যতক্ষণ পর্যন্ত API একটি ত্রুটি ফেরত না দেয়, ধীরে ধীরে হারের সীমা বাড়ান (1% প্রতি মিনিটে)। প্রতিবার আপনি কোটায় পৌঁছান, আপনার অনুরোধের হার 20% কমিয়ে দিন। এই অভিযোজিত পদ্ধতির ফলে ব্যবহারকারী-মুখী ক্রিয়াকলাপের জন্য বিলম্বতা হ্রাস করার সাথে সাথে আরও অনুকূল অনুরোধের হার পাওয়া যায়।