ব্যবহারের সীমা

যেহেতু Google Workspace ইভেন্ট এপিআই একটি শেয়ার করা পরিষেবা, তাই আমরা কোটা এবং সীমাবদ্ধতাগুলি প্রয়োগ করি যাতে নিশ্চিত করা যায় যে এটি সমস্ত ব্যবহারকারীরা ন্যায্যভাবে ব্যবহার করছে এবং Google Workspace-এর সামগ্রিক পারফরম্যান্স সুরক্ষিত রাখতে।

আপনি একটি কোটা অতিক্রম করলে, আপনি একটি 429: Too many requests HTTP স্থিতি কোড প্রতিক্রিয়া৷ Google Workspace Events API ব্যাকএন্ডে অতিরিক্ত রেট লিমিট চেক করলেও একই সমস্যার প্রতিক্রিয়া তৈরি হতে পারে। এই ত্রুটিটি ঘটলে, আপনার একটি সূচকীয় ব্যাকঅফ অ্যালগরিদম ব্যবহার করা উচিত এবং পরে আবার চেষ্টা করা উচিত। যতক্ষণ না আপনি নিম্নলিখিত সারণীতে তালিকাভুক্ত প্রতি মিনিটের কোটার মধ্যে থাকবেন, আপনি প্রতিদিন কতগুলো অনুরোধ করতে পারবেন তার কোনো সীমা নেই।

প্রতি-প্রকল্প কোটা

প্রতি-প্রকল্প কোটা Google ক্লাউড প্রোজেক্টের জন্য কোয়েরির হারকে সীমিত করে এবং এইভাবে প্রতিটি কোটার জন্য নির্দিষ্ট Google Workspace ইভেন্ট এপিআই পদ্ধতিতে কল করে একটি একক অ্যাপে প্রযোজ্য।

নিম্নলিখিত সারণী বিশদ প্রতি-প্রকল্প ক্যোয়ারী সীমা. আপনি Google ক্লাউড কনসোলে কোটা পৃষ্ঠাতেও এই সীমাগুলি খুঁজে পেতে পারেন৷

প্রতি-প্রকল্প কোটা

Google Workspace ইভেন্ট API পদ্ধতি

সীমা

প্রতি মিনিটে লেখে

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

600

ব্যবহারকারী প্রতি মিনিটে লেখে

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

100

প্রতি মিনিটে পড়ে

Subscriptions.get

Subscriptions.list

600

প্রতি মিনিটে প্রতি ব্যবহারকারী পঠিত হয়

Subscriptions.get

Subscriptions.list

100

সময়-ভিত্তিক কোটা ত্রুটিগুলি সমাধান করুন

সমস্ত সময়-ভিত্তিক ত্রুটির জন্য (প্রতি X মিনিটে সর্বাধিক N অনুরোধ), আমরা সুপারিশ করি যে আপনার কোডটি ব্যতিক্রম ক্যাচ করে এবং আপনার ডিভাইসগুলি অত্যধিক লোড তৈরি না করে তা নিশ্চিত করার জন্য একটি ছোট সূচক ব্যাকঅফ ব্যবহার করুন৷

সূচকীয় ব্যাকঅফ হল নেটওয়ার্ক অ্যাপ্লিকেশনগুলির জন্য একটি আদর্শ ত্রুটি পরিচালনার কৌশল। একটি এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম অনুরোধের মধ্যে সর্বোচ্চ ব্যাকঅফ টাইম পর্যন্ত দ্রুতগতিতে বাড়ানোর অপেক্ষার সময় ব্যবহার করে অনুরোধের পুনঃপ্রচার করে। অনুরোধগুলি এখনও অসফল হলে, অনুরোধ সফল না হওয়া পর্যন্ত অনুরোধগুলির মধ্যে বিলম্ব সময়ের সাথে বৃদ্ধি পাওয়া গুরুত্বপূর্ণ।

উদাহরণ অ্যালগরিদম

একটি সূচকীয় ব্যাকঅফ অ্যালগরিদম দ্রুততার সাথে পুনরায় চেষ্টা করে, পুনঃপ্রচারের মধ্যে অপেক্ষার সময়কে সর্বোচ্চ ব্যাকঅফ সময় পর্যন্ত বাড়িয়ে দেয়। যেমন:

  1. Google Workspace Events API-কে অনুরোধ করুন।
  2. অনুরোধ ব্যর্থ হলে, 1 + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
  3. অনুরোধ ব্যর্থ হলে, 2 + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
  4. অনুরোধ ব্যর্থ হলে, 4 + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
  5. এবং তাই, maximum_backoff সময় পর্যন্ত।
  6. কিছু সর্বোচ্চ সংখ্যক পুনঃপ্রচেষ্টা পর্যন্ত অপেক্ষা করা এবং পুনরায় চেষ্টা করা চালিয়ে যান, তবে পুনরায় চেষ্টার মধ্যে অপেক্ষার সময় বাড়াবেন না।

কোথায়:

  • অপেক্ষার সময় হল min(((2^n)+random_number_milliseconds), maximum_backoff) , প্রতিটি পুনরাবৃত্তির (অনুরোধ) জন্য n 1 দ্বারা বৃদ্ধি করা হয়েছে।
  • random_number_milliseconds হল 1,000 এর থেকে কম বা সমান মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা। এটি এমন ঘটনাগুলি এড়াতে সাহায্য করে যেখানে অনেক ক্লায়েন্ট কিছু পরিস্থিতির দ্বারা সিঙ্ক্রোনাইজ করা হয় এবং সিঙ্ক্রোনাইজড তরঙ্গে অনুরোধ পাঠানোর জন্য একবারে পুনরায় চেষ্টা করুন। random_number_milliseconds মান প্রতিটি পুনরায় চেষ্টা করার অনুরোধের পরে পুনরায় গণনা করা হয়।
  • maximum_backoff সাধারণত 32 বা 64 সেকেন্ড। উপযুক্ত মান ব্যবহারের ক্ষেত্রে নির্ভর করে।

ক্লায়েন্ট maximum_backoff সময়ে পৌঁছে যাওয়ার পরে পুনরায় চেষ্টা চালিয়ে যেতে পারে। এই পয়েন্টের পরে পুনরায় চেষ্টা করলে ব্যাকঅফ সময় বাড়ানোর প্রয়োজন নেই। উদাহরণস্বরূপ, যদি একটি ক্লায়েন্ট সর্বোচ্চ 64 সেকেন্ডের maximum_backoff সময় ব্যবহার করে, তাহলে এই মানটিতে পৌঁছানোর পরে, ক্লায়েন্ট প্রতি 64 সেকেন্ডে পুনরায় চেষ্টা করতে পারে। কিছু সময়ে, ক্লায়েন্টদের অনির্দিষ্টকালের জন্য পুনরায় চেষ্টা করা থেকে বিরত রাখা উচিত।

পুনরায় চেষ্টা এবং পুনঃপ্রচারের সংখ্যার মধ্যে অপেক্ষার সময় আপনার ব্যবহারের ক্ষেত্রে এবং নেটওয়ার্কের অবস্থার উপর নির্ভর করে।

প্রতি-প্রকল্প কোটা বৃদ্ধির জন্য অনুরোধ করুন

আপনার প্রকল্পের সম্পদ ব্যবহারের উপর নির্ভর করে, আপনি একটি কোটা বৃদ্ধির অনুরোধ করতে চাইতে পারেন। একটি পরিষেবা অ্যাকাউন্ট দ্বারা API কলগুলি একটি একক অ্যাকাউন্ট ব্যবহার করে বলে মনে করা হয়। বর্ধিত কোটার জন্য আবেদন অনুমোদনের নিশ্চয়তা দেয় না। বড় কোটা বৃদ্ধি অনুমোদন হতে আরও বেশি সময় লাগতে পারে।

সব প্রকল্পে একই কোটা নেই। আপনি সময়ের সাথে সাথে Google ক্লাউড ক্রমবর্ধমান ব্যবহার করছেন, আপনার কোটা বাড়ানোর প্রয়োজন হতে পারে। আপনি যদি ব্যবহারে একটি উল্লেখযোগ্য আসন্ন বৃদ্ধি আশা করেন, আপনি Google ক্লাউড কনসোলে কোটা পৃষ্ঠা থেকে সক্রিয়ভাবে কোটা সমন্বয়ের জন্য অনুরোধ করতে পারেন।

আরও জানতে, নিম্নলিখিত সংস্থানগুলি দেখুন:

,

যেহেতু Google Workspace ইভেন্ট এপিআই একটি শেয়ার করা পরিষেবা, তাই আমরা কোটা এবং সীমাবদ্ধতাগুলি প্রয়োগ করি যাতে নিশ্চিত করা যায় যে এটি সমস্ত ব্যবহারকারীরা ন্যায্যভাবে ব্যবহার করছে এবং Google Workspace-এর সামগ্রিক পারফরম্যান্স সুরক্ষিত রাখতে।

আপনি একটি কোটা অতিক্রম করলে, আপনি একটি 429: Too many requests HTTP স্থিতি কোড প্রতিক্রিয়া৷ Google Workspace Events API ব্যাকএন্ডে অতিরিক্ত রেট লিমিট চেক করলেও একই সমস্যার প্রতিক্রিয়া তৈরি হতে পারে। এই ত্রুটিটি ঘটলে, আপনার একটি সূচকীয় ব্যাকঅফ অ্যালগরিদম ব্যবহার করা উচিত এবং পরে আবার চেষ্টা করা উচিত। যতক্ষণ না আপনি নিম্নলিখিত সারণীতে তালিকাভুক্ত প্রতি মিনিটের কোটার মধ্যে থাকবেন, আপনি প্রতিদিন কতগুলো অনুরোধ করতে পারবেন তার কোনো সীমা নেই।

প্রতি-প্রকল্প কোটা

প্রতি-প্রকল্প কোটা Google ক্লাউড প্রোজেক্টের জন্য কোয়েরির হারকে সীমিত করে এবং এইভাবে প্রতিটি কোটার জন্য নির্দিষ্ট Google Workspace ইভেন্ট এপিআই পদ্ধতিতে কল করে একটি একক অ্যাপে প্রযোজ্য।

নিম্নলিখিত সারণী বিশদ প্রতি-প্রকল্প ক্যোয়ারী সীমা. আপনি Google ক্লাউড কনসোলে কোটা পৃষ্ঠাতেও এই সীমাগুলি খুঁজে পেতে পারেন৷

প্রতি-প্রকল্প কোটা

Google Workspace ইভেন্ট API পদ্ধতি

সীমা

প্রতি মিনিটে লেখে

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

600

ব্যবহারকারী প্রতি মিনিটে লেখে

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

100

প্রতি মিনিটে পড়ে

Subscriptions.get

Subscriptions.list

600

প্রতি মিনিটে প্রতি ব্যবহারকারী পঠিত হয়

Subscriptions.get

Subscriptions.list

100

সময়-ভিত্তিক কোটা ত্রুটিগুলি সমাধান করুন

সমস্ত সময়-ভিত্তিক ত্রুটির জন্য (প্রতি X মিনিটে সর্বাধিক N অনুরোধ), আমরা সুপারিশ করি যে আপনার কোডটি ব্যতিক্রম ক্যাচ করে এবং আপনার ডিভাইসগুলি অত্যধিক লোড তৈরি না করে তা নিশ্চিত করার জন্য একটি ছোট সূচক ব্যাকঅফ ব্যবহার করুন৷

সূচকীয় ব্যাকঅফ হল নেটওয়ার্ক অ্যাপ্লিকেশনগুলির জন্য একটি আদর্শ ত্রুটি পরিচালনার কৌশল। একটি এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম অনুরোধের মধ্যে সর্বোচ্চ ব্যাকঅফ টাইম পর্যন্ত দ্রুতগতিতে বাড়ানোর অপেক্ষার সময় ব্যবহার করে অনুরোধের পুনঃপ্রচার করে। অনুরোধগুলি এখনও অসফল হলে, অনুরোধ সফল না হওয়া পর্যন্ত অনুরোধগুলির মধ্যে বিলম্ব সময়ের সাথে বৃদ্ধি পাওয়া গুরুত্বপূর্ণ।

উদাহরণ অ্যালগরিদম

একটি সূচকীয় ব্যাকঅফ অ্যালগরিদম দ্রুততার সাথে পুনরায় চেষ্টা করে, পুনঃপ্রচারের মধ্যে অপেক্ষার সময়কে সর্বোচ্চ ব্যাকঅফ সময় পর্যন্ত বাড়িয়ে দেয়। যেমন:

  1. Google Workspace Events API-কে অনুরোধ করুন।
  2. অনুরোধ ব্যর্থ হলে, 1 + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
  3. অনুরোধ ব্যর্থ হলে, 2 + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
  4. অনুরোধ ব্যর্থ হলে, 4 + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
  5. এবং তাই, maximum_backoff সময় পর্যন্ত।
  6. কিছু সর্বোচ্চ সংখ্যক পুনঃপ্রচেষ্টা পর্যন্ত অপেক্ষা করা এবং পুনরায় চেষ্টা করা চালিয়ে যান, তবে পুনরায় চেষ্টার মধ্যে অপেক্ষার সময় বাড়াবেন না।

কোথায়:

  • অপেক্ষার সময় হল min(((2^n)+random_number_milliseconds), maximum_backoff) , প্রতিটি পুনরাবৃত্তির (অনুরোধ) জন্য n 1 দ্বারা বৃদ্ধি করা হয়েছে।
  • random_number_milliseconds হল 1,000 এর থেকে কম বা সমান মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা। এটি এমন ঘটনাগুলি এড়াতে সাহায্য করে যেখানে অনেক ক্লায়েন্ট কিছু পরিস্থিতির দ্বারা সিঙ্ক্রোনাইজ করা হয় এবং সিঙ্ক্রোনাইজড তরঙ্গে অনুরোধ পাঠানোর জন্য একবারে পুনরায় চেষ্টা করুন। random_number_milliseconds মান প্রতিটি পুনরায় চেষ্টা করার অনুরোধের পরে পুনরায় গণনা করা হয়।
  • maximum_backoff সাধারণত 32 বা 64 সেকেন্ড। উপযুক্ত মান ব্যবহারের ক্ষেত্রে নির্ভর করে।

ক্লায়েন্ট maximum_backoff সময়ে পৌঁছে যাওয়ার পরে পুনরায় চেষ্টা চালিয়ে যেতে পারে। এই পয়েন্টের পরে পুনরায় চেষ্টা করলে ব্যাকঅফ সময় বাড়ানোর প্রয়োজন নেই। উদাহরণস্বরূপ, যদি একটি ক্লায়েন্ট সর্বোচ্চ 64 সেকেন্ডের maximum_backoff সময় ব্যবহার করে, তাহলে এই মানটিতে পৌঁছানোর পরে, ক্লায়েন্ট প্রতি 64 সেকেন্ডে পুনরায় চেষ্টা করতে পারে। কিছু সময়ে, ক্লায়েন্টদের অনির্দিষ্টকালের জন্য পুনরায় চেষ্টা করা থেকে বিরত রাখা উচিত।

পুনরায় চেষ্টা এবং পুনঃপ্রচারের সংখ্যার মধ্যে অপেক্ষার সময় আপনার ব্যবহারের ক্ষেত্রে এবং নেটওয়ার্কের অবস্থার উপর নির্ভর করে।

প্রতি-প্রকল্প কোটা বৃদ্ধির জন্য অনুরোধ করুন

আপনার প্রকল্পের সম্পদ ব্যবহারের উপর নির্ভর করে, আপনি একটি কোটা বৃদ্ধির অনুরোধ করতে চাইতে পারেন। একটি পরিষেবা অ্যাকাউন্ট দ্বারা API কলগুলি একটি একক অ্যাকাউন্ট ব্যবহার করে বলে মনে করা হয়। বর্ধিত কোটার জন্য আবেদন অনুমোদনের নিশ্চয়তা দেয় না। বড় কোটা বৃদ্ধি অনুমোদন হতে আরও বেশি সময় লাগতে পারে।

সব প্রকল্পে একই কোটা নেই। আপনি সময়ের সাথে সাথে Google ক্লাউড ক্রমবর্ধমান ব্যবহার করছেন, আপনার কোটা বাড়ানোর প্রয়োজন হতে পারে। আপনি যদি ব্যবহারে একটি উল্লেখযোগ্য আসন্ন বৃদ্ধি আশা করেন, আপনি Google ক্লাউড কনসোলে কোটা পৃষ্ঠা থেকে সক্রিয়ভাবে কোটা সমন্বয়ের জন্য অনুরোধ করতে পারেন।

আরও জানতে, নিম্নলিখিত সংস্থানগুলি দেখুন: