আমাদের লক্ষ্য হল FCM ব্যবহার করে প্রেরিত প্রতিটি বার্তা সর্বদা বিলি করা। যাইহোক, প্রতিটি বার্তা প্রদান করার ফলে কখনও কখনও একটি খারাপ সামগ্রিক ব্যবহারকারীর অভিজ্ঞতা হয়। অন্যান্য ক্ষেত্রে, FCM সকল প্রেরকের জন্য একটি পরিমাপযোগ্য পরিষেবা প্রদান করে তা নিশ্চিত করার জন্য আমাদের সীমানা প্রদান করতে হবে। এই বিভাগে বর্ণিত সীমা এবং কোটার প্রকারগুলি আমাদের এই গুরুত্বপূর্ণ বিষয়গুলির ভারসাম্য বজায় রাখতে সাহায্য করে।
ডাউনস্ট্রিম মেসেজ থ্রটলিং
HTTP v1 API প্রবর্তিত হয়েছে প্রতি-প্রকল্প, প্রতি মিনিটের কোটা ডাউনস্ট্রিম মেসেজিংয়ের জন্য। প্রতি মিনিটে 600k বার্তাগুলির ডিফল্ট কোটা 99% FCM বিকাশকারীদের কভার করে যখন সিস্টেমের স্থিতিশীলতা রক্ষা করে এবং স্পাইকি প্রকল্পগুলির প্রভাবকে কম করে।
স্পাইকি ট্রাফিক প্যাটার্নের ফলে কোটা অতিক্রম করা ত্রুটি হতে পারে। অতিরিক্ত কোটার পরিস্থিতিতে, পরবর্তী মিনিটে কোটা পুনরায় পূরণ না হওয়া পর্যন্ত সিস্টেমটি HTTP স্ট্যাটাস কোড 429 (QUOTA_EXCEEDED) পরিবেশন করে। ওভারলোড পরিস্থিতিতেও 429 প্রতিক্রিয়া ফেরত দেওয়া হতে পারে, তাই আপনাকে প্রকাশিত সুপারিশ অনুযায়ী 429গুলি পরিচালনা করার জন্য দৃঢ়ভাবে উত্সাহিত করা হচ্ছে৷
উল্লেখ্য যে:
- ডাউনস্ট্রিম কোটা বার্তা পরিমাপ করে, অনুরোধ নয়।
- ক্লায়েন্ট ত্রুটি (HTTP স্ট্যাটাস কোড 400-499) গণনা করা হয় (429 ব্যতীত)।
- কোটা প্রতি মিনিটে, কিন্তু এই মিনিটগুলি ঘড়ির সাথে সারিবদ্ধ নয়।
মনিটরিং কোটা
আপনি Google ক্লাউড কনসোলে কোটা, ব্যবহার এবং ত্রুটিগুলি দেখতে পারেন:
- Google Cloud কনসোলে যান
- APIs এবং পরিষেবাগুলি নির্বাচন করুন৷
- টেবিল তালিকা থেকে, Firebase ক্লাউড মেসেজিং API নির্বাচন করুন
- কোটা এবং সিস্টেম সীমা নির্বাচন করুন।
দ্রষ্টব্য: এই গ্রাফগুলি সঠিকভাবে কোটা মিনিটের সাথে সারিবদ্ধ নয়, যার অর্থ ট্রাফিক কোটার অধীনে আছে বলে মনে হলে 429গুলি পরিবেশন করা হতে পারে৷
কোটা বৃদ্ধির জন্য অনুরোধ করুন
কোটা বৃদ্ধির অনুরোধ করার আগে, নিশ্চিত করুন যে:
- আপনার ব্যবহার নিয়মিতভাবে প্রতিদিন কমপক্ষে 5 টানা মিনিটের জন্য কোটার ≥ 80%।
- আপনার <5% ক্লায়েন্ট ত্রুটি অনুপাত আছে, বিশেষ করে সর্বোচ্চ ট্রাফিকের সময়।
- আপনি স্কেলে বার্তা পাঠানোর জন্য সর্বোত্তম অনুশীলনগুলি মেনে চলেন৷
আপনি যদি এই মানদণ্ডগুলি পূরণ করেন, আপনি +25% পর্যন্ত কোটা বৃদ্ধির অনুরোধ জমা দিতে পারেন এবং FCM অনুরোধটি পূরণ করার জন্য সর্বাত্মক চেষ্টা করবে (কোন বৃদ্ধির নিশ্চয়তা দেওয়া যাবে না)।
একটি আসন্ন লঞ্চ বা অস্থায়ী ইভেন্টের কারণে আপনার যদি আরও ডাউনস্ট্রিম মেসেজিং কোটার প্রয়োজন হয়, অনুরোধটি পরিচালনা করার জন্য পর্যাপ্ত সময় দেওয়ার জন্য কমপক্ষে 15 দিন আগে আপনার কোটার অনুরোধ করুন। বড় অনুরোধের জন্য (> প্রতি মিনিটে 18M বার্তা), কমপক্ষে 30 দিনের নোটিশ প্রয়োজন। লঞ্চ এবং বিশেষ ইভেন্টের অনুরোধগুলি এখনও ক্লায়েন্ট ত্রুটি অনুপাত এবং সর্বোত্তম অনুশীলনের প্রয়োজনীয়তার সাপেক্ষে।
এছাড়াও FCM কোটা সম্পর্কে প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী দেখুন।
বিষয় বার্তা সীমা
বিষয় সাবস্ক্রিপশন যোগ বা সরানোর হার প্রকল্প প্রতি 3,000 QPS এর মধ্যে সীমাবদ্ধ।
বার্তা পাঠানোর হারের জন্য, ফ্যানআউট থ্রটলিং দেখুন।
ফ্যানআউট থ্রটলিং
মেসেজ ফ্যানআউট হল একাধিক ডিভাইসে একটি বার্তা পাঠানোর প্রক্রিয়া, যেমন আপনি যখন বিষয় এবং গোষ্ঠীগুলিকে টার্গেট করেন বা যখন আপনি শ্রোতা বা ব্যবহারকারীর অংশগুলিকে লক্ষ্য করতে বিজ্ঞপ্তি কম্পোজার ব্যবহার করেন৷
বার্তা ফ্যানআউট তাত্ক্ষণিক নয় এবং তাই মাঝে মাঝে আপনার একাধিক ফ্যানআউট একই সাথে চলছে। আমরা প্রতি প্রজেক্টের সমবর্তী বার্তা ফ্যানআউটের সংখ্যা 1,000-এ সীমাবদ্ধ করি। এর পরে, আমরা অতিরিক্ত ফ্যানআউট অনুরোধগুলি প্রত্যাখ্যান করতে পারি বা অনুরোধগুলির ফ্যানআউটকে পিছিয়ে দিতে পারি যতক্ষণ না ইতিমধ্যে কিছু প্রগতিশীল ফ্যানআউট সম্পূর্ণ হয়৷
প্রকৃত অর্জনযোগ্য ফ্যানআউট হার একই সময়ে ফ্যানআউটের অনুরোধকারী প্রকল্পের সংখ্যা দ্বারা প্রভাবিত হয়। একটি স্বতন্ত্র প্রকল্পের জন্য 10,000 QPS এর একটি ফ্যানআউট রেট অস্বাভাবিক নয়, তবে সেই সংখ্যাটি কোনও গ্যারান্টি নয় এবং এটি সিস্টেমে মোট লোডের ফলাফল। এটি লক্ষ্য করা গুরুত্বপূর্ণ যে উপলব্ধ ফ্যানআউট ক্ষমতা প্রকল্পগুলির মধ্যে বিভক্ত এবং ফ্যানআউট অনুরোধগুলির মধ্যে নয়৷ সুতরাং, যদি আপনার প্রকল্পের দুটি ফ্যানআউট প্রগতিতে থাকে, তাহলে প্রতিটি ফ্যানআউট উপলব্ধ ফ্যানআউট হারের অর্ধেক দেখতে পাবে। আপনার ফ্যানআউট গতি সর্বাধিক করার প্রস্তাবিত উপায় হল একটি সময়ে শুধুমাত্র একটি সক্রিয় ফ্যানআউট প্রগতিশীল।
সংকোচনযোগ্য বার্তা থ্রোটলিং
সংকোচনযোগ্য বার্তাগুলিতে বর্ণিত হিসাবে, সংকোচনযোগ্য বার্তাগুলি একে অপরের উপরে ভেঙে পড়ার জন্য ডিজাইন করা বিষয়বস্তু-মুক্ত বিজ্ঞপ্তি। কোনো ডেভেলপার কোনো অ্যাপে একই বার্তা বারবার পুনরাবৃত্তি করলে, ব্যবহারকারীর ব্যাটারির উপর প্রভাব কমাতে আমরা বার্তাগুলিকে বিলম্বিত করি (থ্রটল)।
উদাহরণস্বরূপ, যদি আপনি একটি একক ডিভাইসে বিপুল সংখ্যক নতুন ইমেল সিঙ্ক অনুরোধ পাঠান, আমরা পরবর্তী ইমেল সিঙ্ক অনুরোধটি কয়েক মিনিট বিলম্ব করতে পারি যাতে ডিভাইসটি কম গড় হারে সিঙ্ক করতে পারে। ব্যবহারকারীর দ্বারা অভিজ্ঞ ব্যাটারি প্রভাব সীমিত করার জন্য এই থ্রটলিং কঠোরভাবে করা হয়।
যদি আপনার ব্যবহারের ক্ষেত্রে উচ্চ বিস্ফোরণ প্রেরণের প্যাটার্নের প্রয়োজন হয়, তাহলে অ-সংকোচনযোগ্য বার্তাগুলি সঠিক পছন্দ হতে পারে। এই ধরনের বার্তাগুলির জন্য, ব্যাটারির খরচ কমানোর জন্য এই ধরনের বার্তাগুলিতে বিষয়বস্তু অন্তর্ভুক্ত করা নিশ্চিত করুন৷
আমরা প্রতি 3 মিনিটে 1টি বার্তা রিফিল সহ প্রতি ডিভাইস প্রতি অ্যাপ প্রতি 20টি বার্তার বিস্ফোরণে সংকোচনযোগ্য বার্তাগুলিকে সীমাবদ্ধ করি।
একটি ডিভাইসে সর্বাধিক বার্তা হার
অ্যান্ড্রয়েডের জন্য, আপনি একটি ডিভাইসে প্রতি মিনিটে 240টি বার্তা এবং প্রতি ঘন্টায় 5,000টি বার্তা পাঠাতে পারেন৷ এই উচ্চ থ্রেশহোল্ডটি স্বল্পমেয়াদী ট্র্যাফিকের বিস্ফোরণের অনুমতি দেওয়ার জন্য বোঝানো হয়েছে, যেমন ব্যবহারকারীরা যখন চ্যাটে দ্রুত যোগাযোগ করে। এই সীমাটি একটি ডিভাইসে অসাবধানতাবশত ব্যাটারি নিষ্কাশন থেকে যুক্তি প্রেরণে ত্রুটি প্রতিরোধ করে৷
iOS-এর জন্য, যখন হার APN-এর সীমা অতিক্রম করে তখন আমরা একটি ত্রুটি ফেরত দিই।