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-এর মতো ডিস্ট্রিবিউটেড, কম-লেটেন্সি ইন-মেমরি ডেটাস্টোরে টোকেন ম্যানেজ করতে পারেন, যেখানে প্রতিটি ক্লায়েন্ট অনুরোধ প্রসেস করার আগে টোকেন সংগ্রহ ও ব্যবহার করে। টোকেন শেষ হয়ে গেলে, টোকেনের পরবর্তী ব্যাচ রিপ্লেনিশ না হওয়া পর্যন্ত ক্লায়েন্ট অপেক্ষা করে।
সারিতে রাখা
অপারেশন লোড ডিস্ট্রিবিউশনের জন্য মেসেজ কিউ হল সমাধান, একই সাথে অনুরোধ এবং গ্রাহকের রেট নিয়ন্ত্রণ করে। মেসেজ কিউয়ের জন্য অনেক বিকল্প উপলভ্য আছে—কিছু ওপেন সোর্স, কিছু মালিকানাধীন—এবং এর মধ্যে অনেকগুলি বিভিন্ন ভাষার সাথে কাজ করতে পারে।
মেসেজ কিউ ব্যবহার করার সময়, আপনার কাছে একাধিক প্রোডিউসার থাকতে পারে যারা কিউতে মেসেজ পুশ করে এবং একাধিক কনজিউমার যারা সেইসব মেসেজ প্রসেস করে। গ্রাহকের দিক থেকে থ্রটল প্রয়োগ করা যেতে পারে, একই সময়ে গ্রাহকের সংখ্যা সীমিত করে অথবা রেট লিমিটর বা থ্রটলার প্রয়োগ করে, প্রডিউসার বা গ্রাহক, যেকোনও একজনের জন্য।
যেমন, কোনও মেসেজ কনজিউমার রেট লিমিট সংক্রান্ত সমস্যার সম্মুখীন হলে, সেই কনজিউমার স্ট্যান্ডার্ডাইজড রিট্রাই ডিলে (এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করে) সহ অনুরোধটি সারিতে ফিরিয়ে দিতে এবং শেয়ার করা রেট-লিমিটার ফিডব্যাক লুপ আপডেট করতে পারে যাতে সমস্যা থেকে বেরিয়ে আসার সময় সব কনজিউমার অটোমেটিক তাদের প্রসেসিং রেট কমিয়ে দেয়।