Google Ads API, কাস্টমার আইডি এবং Google Cloud প্রোজেক্ট, দুটির ক্ষেত্রেই স্বাধীনভাবে প্রতি সেকেন্ডে কোয়েরি (QPS) অনুযায়ী রেট লিমিট এনফোর্স করে। প্রতি মিনিটে অনুরোধের (যা API কলের ফ্রিকোয়েন্সি পরিমাপ করে) পাশাপাশি, Google Ads API প্রতি মিনিটে অপারেশনের (যা অনুরোধ জুড়ে API অপারেশনের মোট সংখ্যা পরিমাপ করে) উপরও সীমা আরোপ করে। Google Ads API, অনুরোধ পরিমাপ করতে এবং উপযুক্ত QPS সীমা নির্ধারণ করতে একটি টোকেন বাকেট অ্যালগরিদম ব্যবহার করে, তাই কোনও নির্দিষ্ট সময়ে সামগ্রিক সার্ভার লোডের উপর নির্ভর করে সঠিক সীমা পরিবর্তিত হয়।
রেট লিমিট আরোপ করার উদ্দেশ্য হল, কোনও একজন ব্যবহারকারী যাতে (ইচ্ছাকৃত বা অনিচ্ছাকৃতভাবে) অত্যধিক বেশি সংখ্যক অনুরোধের মাধ্যমে Google Ads API সার্ভারকে ওভারলোড করে অন্যান্য ব্যবহারকারীদের জন্য পরিষেবা ব্যাহত করতে না পারেন তা প্রতিরোধ করা।
রেট সীমা লঙ্ঘন করে এমন অনুরোধ এই সমস্যার সাথে বাতিল করা হয়:
RESOURCE_TEMPORARILY_EXHAUSTED।
আপনি নিজের অ্যাপের নিয়ন্ত্রণ নিতে এবং অনুরোধের সংখ্যা কমিয়ে ও ক্লায়েন্ট সাইড থেকে QPS থ্রটল করে রেট লিমিট কমানোর মাধ্যমে তা করতে পারেন।
রেট লিমিট অতিক্রম করার সম্ভাবনা কমানোর জন্য একাধিক উপায় রয়েছে। এন্টারপ্রাইজ ইন্টিগ্রেশন প্যাটার্ন (EIP) ধারণা যেমন মেসেজিং, রি-ডেলিভারি এবং থ্রটলিংয়ের সাথে পরিচিত হলে আপনি আরও শক্তিশালী ক্লায়েন্ট অ্যাপ তৈরি করতে পারবেন।
নিম্নলিখিত সাজেস্ট করা পদ্ধতিগুলি জটিলতার ক্রম অনুসারে সাজানো হয়েছে, যার মধ্যে সহজ কৌশলগুলি উপরে এবং আরও শক্তিশালী কিন্তু অত্যাধুনিক আর্কিটেকচার পরে রয়েছে:
- এক্সপোনেনশিয়াল ব্যাকঅফ
- একসাথে করা যায় এমন টাস্কের সংখ্যা সীমিত করুন
- ব্যাচিং অনুরোধ
- থ্রটলিং ও রেট লিমিটর
- কিউ করা হচ্ছে
এক্সপোনেনশিয়াল ব্যাকঅফ
আপনার অ্যাপ্লিকেশন কোনও
RESOURCE_TEMPORARILY_EXHAUSTED সমস্যা পেলে, ব্যর্থ
অনুরোধ আবার করার আগে র্যান্ডমাইজড জিটার সহ একটি
এক্সপোনেনশিয়াল ব্যাকঅফ নীতি ব্যবহার করুন। এক্সপোনেনশিয়াল ব্যাকঅফ, আবার চেষ্টা করার মধ্যে অপেক্ষার সময়কে
ধীরে ধীরে বাড়ায় (যেমন, ২ সেকেন্ড অপেক্ষা করা, তারপর ৪ সেকেন্ড, তারপর ৮ সেকেন্ড, সাথে
ছোট র্যান্ডম বিলম্ব), যা সার্ভার লোড ও কোটা বাকেটকে রিকভার করার সুযোগ দেয় এবং
ক্লায়েন্ট ইনস্ট্যান্স জুড়ে সিঙ্ক্রোনাইজ করা আবার চেষ্টা করার স্পাইক প্রতিরোধ করে।
একই সাথে করা যায় এমন টাস্কের সংখ্যা সীমিত করা
রেট লিমিট অতিক্রম করার একটি মূল কারণ হল ক্লায়েন্ট অ্যাপটি অতিরিক্ত সংখ্যক প্যারালাল টাস্ক তৈরি করছে। আমরা ক্লায়েন্ট অ্যাপের সমান্তরাল অনুরোধের সংখ্যা সীমিত না করলেও, এটি Google Cloud প্রোজেক্ট লেভেলে প্রতি সেকেন্ডে অনুরোধের সীমা অতিক্রম করতে পারে।
একসাথে করা যায় এমন টাস্কের মোট সংখ্যার জন্য একটি যুক্তিসঙ্গত ঊর্ধ্বসীমা সেট করা যা অনুরোধ করতে চলেছে (সব প্রসেস এবং মেশিন জুড়ে), এবং রেট সীমা অতিক্রম না করে আপনার থ্রুপুট অপ্টিমাইজ করার জন্য উপরের দিকে অ্যাডজাস্ট করার সুপারিশ করা হয়।
এছাড়াও, আপনি ক্লায়েন্ট সাইড থেকে QPS থ্রটল করার কথা বিবেচনা করতে পারেন (দেখুন থ্রটল করা ও রেট লিমিটার)।
ব্যাচ করা অনুরোধ
একটি অনুরোধে একাধিক অপারেশন ব্যাচ করার কথা বিবেচনা করুন। এটি বিভিন্ন পরিষেবার জন্য Mutate কলের ক্ষেত্রে সবচেয়ে বেশি
প্রযোজ্য। যেমন, আপনি যদি একাধিক AdGroupAd-এর স্ট্যাটাস
আপডেট করেন, তাহলে আপনি একবার MutateAdGroupAds কল করতে পারেন এবং প্রতিটি
AdGroupAd-এর জন্য একবার করে
MutateAdGroupAds কল করার পরিবর্তে একাধিক
operations পাস করতে পারেন। আরও কিছু উদাহরণের জন্য আমাদের
ব্যাচ অপারেশন সংক্রান্ত নির্দেশিকা দেখুন।
ব্যাচিং অনুরোধগুলি API কলের মোট সংখ্যা কমিয়ে দেয় এবং প্রতি মিনিটে অনুরোধের রেট সীমা কমিয়ে দেয়, তবে আপনি যদি একটি অ্যাকাউন্টের জন্য প্রচুর সংখ্যক অপারেশন করেন তবে এটি প্রতি মিনিটে অপারেশনের রেট সীমা ট্রিগার করতে পারে।
থ্রটলিং ও রেট লিমিটার
আপনার অ্যাপ্লিকেশনে থ্রেডের মোট সংখ্যা সীমিত করার পাশাপাশি, আপনি ক্লায়েন্ট সাইডেও রেট লিমিটার প্রয়োগ করতে পারেন। এটি নিশ্চিত করে যে আপনার প্রসেস, ক্লাস্টার বা দুটির সব থ্রেড ক্লায়েন্ট সাইড থেকে একটি নির্দিষ্ট QPS সীমা দ্বারা পরিচালিত হয়।
Guava RateLimiter দেখুন অথবা ক্লাস্টার করা এনভায়রনমেন্টের জন্য আপনার নিজস্ব টোকেন বাকেট অ্যালগরিদম প্রয়োগ করুন। যেমন, আপনি Redis বা Memcached-এর মতো ডিস্ট্রিবিউটেড, কম-লেটেন্সি ইন-মেমরি ডেটাস্টোরে টোকেন ম্যানেজ করতে পারেন, যেখানে প্রতিটি ক্লায়েন্ট অনুরোধ প্রসেস করার আগে টোকেন সংগ্রহ ও ব্যবহার করে। টোকেন শেষ হয়ে গেলে, টোকেনের পরবর্তী ব্যাচ না আসা পর্যন্ত ক্লায়েন্ট অপেক্ষা করে।
সারিতে রাখা
মেসেজ কিউ হল অপারেশন লোড ডিস্ট্রিবিউশনের সমাধান, একই সাথে অনুরোধ এবং গ্রাহকের রেট নিয়ন্ত্রণ করে। মেসেজ কিউ সংক্রান্ত বিভিন্ন বিকল্প উপলভ্য—কিছু ওপেন সোর্স, কিছু প্রোপাইটরি—এবং এগুলির মধ্যে অনেকগুলি বিভিন্ন ভাষার সাথে কাজ করতে পারে।
মেসেজ কিউ ব্যবহার করার সময়, আপনার কাছে একাধিক প্রোডিউসার থাকতে পারে যারা কিউতে মেসেজ পুশ করে এবং একাধিক কনজিউমার যারা সেইসব মেসেজ প্রসেস করে। কনজিউমার সাইডে কনকারেন্ট কনজিউমারের সংখ্যা সীমিত করে অথবা প্রযোজক বা কনজিউমারদের জন্য রেট লিমিটার বা থ্রটলার প্রয়োগ করে থ্রটল প্রয়োগ করা যেতে পারে।
যেমন, কোনও মেসেজ কনজিউমার রেট লিমিট সংক্রান্ত সমস্যার সম্মুখীন হলে, সেই কনজিউমার স্ট্যান্ডার্ডাইজড রিট্রাই ডিলে (এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করে) সহ অনুরোধটি কিউতে ফেরত পাঠাতে এবং শেয়ার করা রেট-লিমিটার ফিডব্যাক লুপ আপডেট করতে পারে যাতে সমস্যা থেকে বেরিয়ে আসার সময় সব কনজিউমার অটোমেটিক তাদের প্রসেসিং রেট কমিয়ে দেয়।