যেহেতু Google Chat API একটি শেয়ার করা পরিষেবা, তাই আমরা কোটা এবং সীমাবদ্ধতাগুলি প্রয়োগ করি যাতে নিশ্চিত করা যায় যে এটি সমস্ত ব্যবহারকারীরা সঠিকভাবে ব্যবহার করছে এবং Google Workspace-এর সামগ্রিক পারফরম্যান্স সুরক্ষিত রাখতে।
আপনি একটি কোটা অতিক্রম করলে, আপনি একটি 429: Too many requests HTTP স্থিতি কোড প্রতিক্রিয়া৷ চ্যাট ব্যাকএন্ডে অতিরিক্ত রেট লিমিট চেকও একই ত্রুটির প্রতিক্রিয়া তৈরি করতে পারে। এই ত্রুটিটি ঘটলে, আপনার একটি সূচকীয় ব্যাকঅফ অ্যালগরিদম ব্যবহার করা উচিত এবং পরে আবার চেষ্টা করা উচিত। যতক্ষণ না আপনি নিম্নলিখিত সারণীতে তালিকাভুক্ত প্রতি মিনিটের কোটার মধ্যে থাকবেন, আপনি প্রতিদিন কতগুলো অনুরোধ করতে পারবেন তার কোনো সীমা নেই।
দুটি কোটা প্রকার চ্যাট API পদ্ধতিতে প্রযোজ্য: প্রতি-স্পেস এবং প্রতি-প্রকল্প কোটা।
স্থান প্রতি কোটা
প্রতি-স্পেস কোটা একটি প্রদত্ত স্পেসে কোয়েরির হারকে সীমিত করে এবং প্রতিটি কোটার জন্য তালিকাভুক্ত চ্যাট API পদ্ধতিগুলিকে কল করে সেই স্পেসে কাজ করা সমস্ত চ্যাট অ্যাপের মধ্যে ভাগ করা হয়।
নিম্নোক্ত টেবিলের বিবরণ প্রতি-স্পেস ক্যোয়ারী সীমা:
প্রতি-স্পেস কোটা | চ্যাট API পদ্ধতি | সীমা (প্রতি 60 সেকেন্ড, ভাগ করা হয়েছে |
|---|---|---|
প্রতি মিনিটে পড়ে | | 900 |
প্রতি মিনিটে লিখে | | 60 |
প্রতি-প্রকল্প কোটা
প্রতি-প্রকল্প কোটাগুলি একটি Google ক্লাউড প্রকল্পের জন্য প্রশ্নের হারকে সীমিত করে এবং এইভাবে প্রতিটি কোটার জন্য নির্দিষ্ট চ্যাট API পদ্ধতিতে কল করে একটি একক চ্যাট অ্যাপে প্রযোজ্য।
নিম্নলিখিত সারণী বিশদ প্রতি-প্রকল্প ক্যোয়ারী সীমা. আপনি কোটা পৃষ্ঠাতেও এই সীমাগুলি খুঁজে পেতে পারেন।
প্রতি-প্রকল্প কোটা | চ্যাট API পদ্ধতি | সীমা (প্রতি 60 সেকেন্ড) |
|---|---|---|
প্রতি মিনিটে বার্তা লেখা হয় | | 3000 |
বার্তা প্রতি মিনিটে পড়া হয় | | 3000 |
সদস্যপদ প্রতি মিনিটে লিখে | | 300 |
সদস্যপদ প্রতি মিনিটে পড়ে | | 3000 |
স্পেস প্রতি মিনিটে লিখে | | 60 |
প্রতি মিনিটে স্থান পড়ে | | 3000 |
সংযুক্তি প্রতি মিনিটে লেখা | | 600 |
সংযুক্তি প্রতি মিনিটে পড়া হয় | | 3000 |
প্রতি মিনিটে প্রতিক্রিয়া লিখছে | | 600 |
প্রতিক্রিয়া প্রতি মিনিটে পড়ে | | 3000 |
অতিরিক্ত ব্যবহারের সীমা
GROUP_CHAT বা SPACE টাইপের স্পেস তৈরির জন্য অতিরিক্ত কোটা সীমা রয়েছে ( spaces.create বা spaces.setup পদ্ধতি ব্যবহার করে)। এই ধরনের প্রতি মিনিটে 35টির কম স্পেস এবং প্রতি ঘন্টায় 800টি স্পেস তৈরি করুন৷ DIRECT_MESSAGE প্রকারের স্থানগুলি এই অতিরিক্ত কোটা সীমার অধীন নয়৷
একই স্থান লক্ষ্য করে উচ্চ API ট্র্যাফিক অতিরিক্ত অভ্যন্তরীণ সীমা ট্রিগার করতে পারে যা কোটা পৃষ্ঠায় দৃশ্যমান নয়।
সময়-ভিত্তিক কোটা ত্রুটিগুলি সমাধান করুন
সমস্ত সময়-ভিত্তিক ত্রুটির জন্য (প্রতি X মিনিটে সর্বাধিক N অনুরোধ), আমরা সুপারিশ করি যে আপনার কোডটি ব্যতিক্রম ক্যাচ করে এবং আপনার ডিভাইসগুলি অত্যধিক লোড তৈরি না করে তা নিশ্চিত করার জন্য একটি ছোট সূচক ব্যাকঅফ ব্যবহার করুন৷
সূচকীয় ব্যাকঅফ হল নেটওয়ার্ক অ্যাপ্লিকেশনগুলির জন্য একটি আদর্শ ত্রুটি পরিচালনার কৌশল। একটি এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম অনুরোধের মধ্যে সর্বোচ্চ ব্যাকঅফ টাইম পর্যন্ত দ্রুতগতিতে বাড়ানোর অপেক্ষার সময় ব্যবহার করে অনুরোধের পুনঃপ্রচার করে। অনুরোধগুলি এখনও অসফল হলে, অনুরোধ সফল না হওয়া পর্যন্ত অনুরোধগুলির মধ্যে বিলম্ব সময়ের সাথে বৃদ্ধি পাওয়া গুরুত্বপূর্ণ।
উদাহরণ অ্যালগরিদম
একটি সূচকীয় ব্যাকঅফ অ্যালগরিদম দ্রুততার সাথে পুনরায় চেষ্টা করে, পুনঃপ্রচারের মধ্যে অপেক্ষার সময়কে সর্বোচ্চ ব্যাকঅফ সময় পর্যন্ত বাড়িয়ে দেয়। যেমন:
- Google Chat API-কে একটি অনুরোধ করুন।
- অনুরোধ ব্যর্থ হলে, 1 +
random_number_millisecondsঅপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন। - অনুরোধ ব্যর্থ হলে, 2 +
random_number_millisecondsঅপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন। - অনুরোধ ব্যর্থ হলে, 4 +
random_number_millisecondsঅপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন। - এবং তাই,
maximum_backoffসময় পর্যন্ত। - কিছু সর্বোচ্চ সংখ্যক পুনঃপ্রচেষ্টা পর্যন্ত অপেক্ষা করা এবং পুনরায় চেষ্টা করা চালিয়ে যান, তবে পুনরায় চেষ্টার মধ্যে অপেক্ষার সময় বাড়াবেন না।
কোথায়:
- অপেক্ষার সময় হল
min(((2^n)+random_number_milliseconds), maximum_backoff), প্রতিটি পুনরাবৃত্তির (অনুরোধ) জন্যn1 দ্বারা বৃদ্ধি করা হয়েছে। -
random_number_millisecondsহল 1,000 এর থেকে কম বা সমান মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা। এটি এমন ঘটনাগুলি এড়াতে সাহায্য করে যেখানে অনেক ক্লায়েন্ট কিছু পরিস্থিতির দ্বারা সিঙ্ক্রোনাইজ করা হয় এবং সিঙ্ক্রোনাইজড তরঙ্গে অনুরোধ পাঠানোর জন্য একবারে পুনরায় চেষ্টা করুন।random_number_millisecondsমান প্রতিটি পুনরায় চেষ্টা করার অনুরোধের পরে পুনরায় গণনা করা হয়। -
maximum_backoffসাধারণত 32 বা 64 সেকেন্ড। উপযুক্ত মান ব্যবহারের ক্ষেত্রে নির্ভর করে।
ক্লায়েন্ট maximum_backoff সময়ে পৌঁছে যাওয়ার পরে পুনরায় চেষ্টা চালিয়ে যেতে পারে। এই পয়েন্টের পরে পুনরায় চেষ্টা করলে ব্যাকঅফ সময় বাড়ানোর প্রয়োজন নেই। উদাহরণস্বরূপ, যদি একটি ক্লায়েন্ট সর্বোচ্চ 64 সেকেন্ডের maximum_backoff সময় ব্যবহার করে, তাহলে এই মানটিতে পৌঁছানোর পরে, ক্লায়েন্ট প্রতি 64 সেকেন্ডে পুনরায় চেষ্টা করতে পারে। কিছু সময়ে, ক্লায়েন্টদের অনির্দিষ্টকালের জন্য পুনরায় চেষ্টা করা থেকে বিরত রাখা উচিত।
পুনরায় চেষ্টা এবং পুনঃপ্রচারের সংখ্যার মধ্যে অপেক্ষার সময় আপনার ব্যবহারের ক্ষেত্রে এবং নেটওয়ার্কের অবস্থার উপর নির্ভর করে।
প্রতি-প্রকল্প কোটা বৃদ্ধির জন্য অনুরোধ করুন
আপনার প্রকল্পের সম্পদ ব্যবহারের উপর নির্ভর করে, আপনি একটি কোটা বৃদ্ধির অনুরোধ করতে চাইতে পারেন। একটি পরিষেবা অ্যাকাউন্ট দ্বারা API কলগুলি একটি একক অ্যাকাউন্ট ব্যবহার করে বলে মনে করা হয়। বর্ধিত কোটার জন্য আবেদন অনুমোদনের নিশ্চয়তা দেয় না। বড় কোটা বৃদ্ধি অনুমোদন হতে আরও বেশি সময় লাগতে পারে।
সব প্রকল্পে একই কোটা নেই। আপনি সময়ের সাথে সাথে Google ক্লাউড ক্রমবর্ধমান ব্যবহার করছেন, আপনার কোটা বাড়ানোর প্রয়োজন হতে পারে। আপনি যদি ব্যবহারে একটি উল্লেখযোগ্য আসন্ন বৃদ্ধি আশা করেন, আপনি Google ক্লাউড কনসোলে কোটা পৃষ্ঠা থেকে সক্রিয়ভাবে কোটা সমন্বয়ের জন্য অনুরোধ করতে পারেন।
আরও জানতে, নিম্নলিখিত সংস্থানগুলি দেখুন: