গুগল ক্যালেন্ডার এপিআই-এর কোটা রয়েছে, যাতে সকল ব্যবহারকারী এর ন্যায্য ব্যবহার নিশ্চিত করতে পারে। ক্যালেন্ডার এপিআই ব্যবহার করার সময় তিনটি গুরুত্বপূর্ণ সীমাবদ্ধতা বিবেচনা করতে হবে:
এপিআই ব্যবহারের কোটা : প্রজেক্ট এবং ব্যবহারকারী প্রতি প্রযোজ্য। আরও তথ্যের জন্য, ক্যালেন্ডার এপিআই ব্যবহারের কোটার প্রকারভেদ দেখুন।
গুগল ক্যালেন্ডার ব্যবহারের সাধারণ সীমাবদ্ধতা : গুগল ক্যালেন্ডার এপিআই একটি শেয়ার্ড সার্ভিস, যার কিছু সীমাবদ্ধতা রয়েছে গুগল ওয়ার্কস্পেস সিস্টেমের সার্বিক পারফরম্যান্স রক্ষা করার জন্য। আরও তথ্যের জন্য, ‘ক্যালেন্ডার ব্যবহারের সীমাবদ্ধতা এড়িয়ে চলুন’ দেখুন।
কার্যক্ষমতার সীমাবদ্ধতা : এই সীমাবদ্ধতাগুলো যেকোনো সময় সীমিত হতে পারে। উদাহরণস্বরূপ, যদি আপনি দ্রুত পরপর একটিমাত্র ক্যালেন্ডারে লেখার চেষ্টা করেন।
ক্যালেন্ডার এপিআই কোটা
দুই ধরনের কোটা বলবৎ করা হয়:
প্রতি মিনিটে প্রতি প্রজেক্টে: এটি হলো সেই অনুরোধের সংখ্যা যা আপনার গুগল ক্লাউড প্রজেক্ট এক মিনিটে করতে পারে।
প্রতি মিনিটে প্রতি ব্যবহারকারী প্রতি প্রজেক্ট: এটি হলো আপনার ক্লাউড প্রজেক্টে কোনো একজন নির্দিষ্ট ব্যবহারকারীর করার অনুরোধের সংখ্যা। এই সীমাটি আপনার ব্যবহারকারীদের মধ্যে ব্যবহারের ন্যায্য বন্টন নিশ্চিত করতে আপনাকে সাহায্য করে।
স্লাইডিং উইন্ডো ব্যবহার করে প্রতি মিনিটের জন্য কোটা গণনা করা হয়। কোনো এক মিনিটে ট্র্যাফিকের আকস্মিক বৃদ্ধি যদি আপনার প্রতি-মিনিটের কোটা অতিক্রম করে, তাহলে পরবর্তী উইন্ডোতে রেট লিমিটিং প্রয়োগ করা হবে, যাতে গড়ে আপনার ব্যবহার কোটার মধ্যেই থাকে।
নিম্নলিখিত সারণিতে এই সীমাগুলো বিস্তারিতভাবে বর্ণনা করা হয়েছে:
| ব্যবহারের সীমাবদ্ধতার ধরণ | সীমা |
|---|---|
| প্রতি মিনিটে প্রতি প্রকল্পে | ১০,০০০ অনুরোধ |
| প্রতি মিনিটে প্রতি ব্যবহারকারী প্রতি প্রকল্পে | ৬০০টি অনুরোধ |
দৈনিক বিলিং সীমা
এই দৈনিক ও প্রকল্প প্রতি সীমাটি নির্ধারণ করে যে, চার্জ প্রযোজ্য হওয়ার আগে আপনার গুগল ক্লাউড প্রকল্প ২৪ ঘণ্টার মধ্যে সর্বাধিক কতগুলো অনুরোধ ব্যবহার করতে পারবে।
এই সীমার কম ব্যবহারে কোনো অতিরিক্ত চার্জ লাগবে না এবং আপনার গুগল ক্লাউড অ্যাকাউন্টে কোনো বিল করা হবে না। সম্পূর্ণ বিলিং বিবরণ ২০২৬ সালের শেষের দিকে জানানো হবে এবং যেকোনো পরিবর্তন কার্যকর হওয়ার অন্তত ৯০ দিন আগে নোটিশ দেওয়া হবে।
আপনি এই দৈনিক সীমা বৃদ্ধির জন্য অনুরোধ করতে পারবেন না।
নিম্নলিখিত সারণিতে সীমাটি বিস্তারিতভাবে বর্ণনা করা হয়েছে:
| থ্রেশহোল্ড সীমা প্রকার | সীমা |
|---|---|
| প্রতিদিন প্রতি প্রকল্পে | ১,০০০,০০০ অনুরোধ |
আরও তথ্যের জন্য, এজেন্ট টুল এবং এপিআই-এর জন্য গুগল ওয়ার্কস্পেসের প্রমিত মডেল দেখুন।
সময়-ভিত্তিক কোটা ত্রুটি সমাধান করুন
সমস্ত সময়-ভিত্তিক ত্রুটির (প্রতি X মিনিটে সর্বোচ্চ N সংখ্যক অনুরোধ) ক্ষেত্রে, আমরা সুপারিশ করি যে আপনার কোড যেন এক্সেপশনটি ক্যাচ করে এবং একটি ট্রাঙ্কেটেড এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করে, যাতে আপনার ডিভাইসগুলো অতিরিক্ত লোড তৈরি না করে।
এক্সপোনেনশিয়াল ব্যাকঅফ হলো নেটওয়ার্ক অ্যাপ্লিকেশনগুলির জন্য একটি আদর্শ ত্রুটি পরিচালনা কৌশল। একটি এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম একটি সর্বোচ্চ ব্যাকঅফ সময় পর্যন্ত, অনুরোধগুলির মধ্যে সূচকীয়ভাবে ক্রমবর্ধমান অপেক্ষার সময় ব্যবহার করে অনুরোধগুলি পুনরায় চেষ্টা করে। যদি অনুরোধগুলি তখনও অসফল হয়, তবে অনুরোধটি সফল না হওয়া পর্যন্ত সময়ের সাথে সাথে অনুরোধগুলির মধ্যে বিলম্ব বাড়ানো গুরুত্বপূর্ণ।
উদাহরণ অ্যালগরিদম
একটি এক্সপোনেনশিয়াল ব্যাকঅফ অ্যালগরিদম অনুরোধগুলোকে সূচকীয় হারে পুনরায় চেষ্টা করে, এবং একটি সর্বোচ্চ ব্যাকঅফ সময় পর্যন্ত পুনরায় চেষ্টার মধ্যবর্তী অপেক্ষার সময় বাড়িয়ে দেয়। উদাহরণস্বরূপ:
- গুগল ক্যালেন্ডার এপিআই-তে একটি অনুরোধ পাঠান।
- অনুরোধটি ব্যর্থ হলে, 1 +
random_number_millisecondsঅপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন। - অনুরোধটি ব্যর্থ হলে, 2 +
random_number_millisecondsঅপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন। - অনুরোধটি ব্যর্থ হলে, 4 +
random_number_millisecondsঅপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন। - এবং এভাবেই চলতে থাকে, একটি
maximum_backoffসময় পর্যন্ত। - একটি নির্দিষ্ট সর্বোচ্চ সংখ্যক বার পর্যন্ত অপেক্ষা করতে ও পুনরায় চেষ্টা করতে থাকুন, কিন্তু দুটি চেষ্টার মধ্যবর্তী অপেক্ষার সময়কাল বাড়াবেন না।
যেখানে:
- অপেক্ষার সময় হলো
min(((2^n)+random_number_milliseconds), maximum_backoff), যেখানে প্রতিটি ইটারেশন (অনুরোধ)-এর জন্যnমান ১ করে বৃদ্ধি পায়। -
random_number_millisecondsহলো ১,০০০ বা তার কম মিলিসেকেন্ডের একটি র্যান্ডম সংখ্যা। এটি এমন পরিস্থিতি এড়াতে সাহায্য করে যেখানে অনেক ক্লায়েন্ট কোনো একটি কারণে সিনক্রোনাইজড হয়ে যায় এবং সবাই একযোগে পুনরায় চেষ্টা করে, অর্থাৎ সিনক্রোনাস তরঙ্গে অনুরোধ পাঠায়। প্রতিটি পুনঃপ্রচেষ্টার অনুরোধের পরrandom_number_millisecondsএর মান পুনরায় গণনা করা হয়। -
maximum_backoffসাধারণত ৩২ বা ৬৪ সেকেন্ড হয়ে থাকে। এর উপযুক্ত মান ব্যবহারের ধরনের ওপর নির্ভর করে।
ক্লায়েন্ট maximum_backoff সময়টিতে পৌঁছানোর পরেও পুনরায় চেষ্টা চালিয়ে যেতে পারে। এই সময়ের পরে পুনরায় চেষ্টার জন্য ব্যাকঅফ সময় আর বাড়ানোর প্রয়োজন নেই। উদাহরণস্বরূপ, যদি কোনো ক্লায়েন্ট ৬৪ সেকেন্ডের maximum_backoff সময় ব্যবহার করে, তবে এই মানে পৌঁছানোর পর ক্লায়েন্টটি প্রতি ৬৪ সেকেন্ড পর পর পুনরায় চেষ্টা করতে পারে। একটি নির্দিষ্ট পর্যায়ে, ক্লায়েন্টদের অনির্দিষ্টকালের জন্য পুনরায় চেষ্টা করা থেকে বিরত রাখা উচিত।
পুনরায় চেষ্টার মধ্যবর্তী অপেক্ষার সময় এবং পুনরায় চেষ্টার সংখ্যা আপনার ব্যবহারের ধরণ এবং নেটওয়ার্ক অবস্থার উপর নির্ভর করে।
মূল্য নির্ধারণ
গুগল ক্যালেন্ডার এপিআই-এর সমস্ত সাধারণ ব্যবহার কোনো অতিরিক্ত খরচ ছাড়াই পাওয়া যায়। কোটা অনুরোধের সীমা অতিক্রম করলে ২০২৬ সালের শেষের দিকে আপনার গুগল ক্লাউড বিলিং অ্যাকাউন্টে চার্জ আরোপ করার পরিকল্পনা রয়েছে। আরও তথ্যের জন্য, এজেন্ট টুল এবং এপিআই-এর জন্য গুগল ওয়ার্কস্পেসের প্রমিত মডেল দেখুন।
কোটা বৃদ্ধির জন্য অনুরোধ করুন
আপনার প্রকল্পের রিসোর্স ব্যবহারের উপর নির্ভর করে, আপনি কোটা সমন্বয়ের জন্য অনুরোধ করতে চাইতে পারেন। একটি সার্ভিস অ্যাকাউন্ট দ্বারা করা এপিআই কলগুলোকে একটি একক অ্যাকাউন্ট হিসেবে বিবেচনা করা হয়। সমন্বয়কৃত কোটার জন্য আবেদন করলেই যে তা অনুমোদিত হবে, এমন কোনো নিশ্চয়তা নেই। যে কোটা সমন্বয়ের অনুরোধগুলো কোটার পরিমাণ উল্লেখযোগ্যভাবে বৃদ্ধি করবে, সেগুলো অনুমোদিত হতে বেশি সময় লাগতে পারে।
সব প্রোজেক্টের কোটা এক নয়। সময়ের সাথে সাথে আপনার গুগল ক্লাউডের ব্যবহার বাড়ার সাথে সাথে আপনার কোটার পরিমাণও বৃদ্ধি করার প্রয়োজন হতে পারে। যদি আপনি ভবিষ্যতে ব্যবহারের উল্লেখযোগ্য বৃদ্ধি প্রত্যাশা করেন, তবে আপনি গুগল ক্লাউড কনসোলের 'Quotas & System Limits' পেজ থেকে আগে থেকেই কোটা সমন্বয়ের জন্য অনুরোধ করতে পারেন।
আরও জানতে, নিম্নলিখিত উৎসগুলো দেখুন:
সমস্যা সমাধান
যদি কোনো কোটা অতিক্রম করা হয়, তাহলে আপনার রেট সীমিত করা হবে এবং আপনার কোয়েরিগুলোর জবাবে আপনি একটি 403 usageLimits স্ট্যাটাস কোড অথবা একটি 429 usageLimits স্ট্যাটাস কোড পাবেন।
এমনটা হলে, আপনি নিম্নলিখিতগুলো চেষ্টা করতে পারেন:
সমস্ত সেরা অনুশীলনগুলো অনুসরণ করা নিশ্চিত করুন: এক্সপোনেনশিয়াল ব্যাকঅফ ব্যবহার করুন, ট্র্যাফিক প্যাটার্ন এলোমেলো করুন এবং পুশ নোটিফিকেশন ব্যবহার করুন।
আপনার প্রজেক্টের পরিধি বাড়লে এবং ব্যবহারকারীর সংখ্যা বৃদ্ধি পেলে, আপনি কোটা বৃদ্ধির জন্য অনুরোধ করতে পারেন।
যদি ব্যবহারকারী-প্রতি কোটার সীমা অতিক্রম করে ফেলেন, তাহলে আপনি নিম্নলিখিত কাজগুলো করতে পারেন:
আপনি যদি একটি সার্ভিস অ্যাকাউন্ট ব্যবহার করেন, তাহলে ব্যবহারকারীদের মধ্যে লোড বন্টন করুন অথবা একাধিক সার্ভিস অ্যাকাউন্টের মধ্যে তা ভাগ করে দিন।
যদিও আপনি ব্যবহারকারী-প্রতি কোটা বাড়ানোর জন্য অনুরোধ করতে পারেন, তবে সাধারণত ডিফল্ট মানের উপরে এটি বাড়ানোর পরামর্শ দেওয়া হয় না, কারণ এতে আপনার অ্যাপ্লিকেশনটি অন্যান্য ধরনের সীমাবদ্ধতায় পৌঁছে যেতে পারে, যেমন—সাধারণ ক্যালেন্ডার ব্যবহারের সীমাবদ্ধতা বা পরিচালনগত সীমাবদ্ধতা।
আপনার প্রোডাকশন প্রজেক্টের অনুরূপ কনফিগারেশন সহ একটি পৃথক শুধুমাত্র-পরীক্ষামূলক প্রজেক্ট রেজিস্টার করে আপনার কোটার সীমা পরীক্ষা করুন। আরও তথ্যের জন্য, ‘কোটা সীমা পরিচালনা পরীক্ষা ’ দেখুন।
ট্র্যাফিক প্যাটার্ন এলোমেলো করুন
একাধিক ক্লায়েন্ট একই সময়ে বিভিন্ন অপারেশন চালানোর কারণে ক্যালেন্ডার ক্লায়েন্টগুলোতে ট্র্যাফিকের আকস্মিক বৃদ্ধির প্রবণতা দেখা যায়। উদাহরণস্বরূপ, ক্যালেন্ডার ক্লায়েন্টের জন্য একটি সাধারণ খারাপ অভ্যাস হলো মধ্যরাতে সম্পূর্ণ সিঙ্ক করা। এর ফলে প্রায় নিশ্চিতভাবেই আপনার প্রতি-মিনিটের কোটা অতিক্রম করবে এবং রেট লিমিটিং ও ব্যাকঅফের মতো পরিস্থিতি তৈরি হবে।
এটি এড়ানোর জন্য, যথাসম্ভব আপনার ট্র্যাফিক যেন সারা দিন জুড়ে ছড়িয়ে থাকে তা নিশ্চিত করুন। যদি আপনার ক্লায়েন্টকে প্রতিদিন সিঙ্ক করার প্রয়োজন হয়, তবে ক্লায়েন্টকে একটি এলোমেলো সময় নির্ধারণ করতে দিন (প্রতিটি ক্লায়েন্টের জন্য আলাদা)। যদি আপনাকে নিয়মিতভাবে কোনো অপারেশন সম্পাদন করতে হয়, তবে ব্যবধানটি +/- ২৫% পর্যন্ত পরিবর্তন করুন। এটি ট্র্যাফিককে আরও সুষমভাবে বন্টন করবে এবং ব্যবহারকারীকে অনেক ভালো অভিজ্ঞতা দেবে।
পুশ নোটিফিকেশন ব্যবহার করুন
এর একটি সাধারণ ব্যবহার হলো ব্যবহারকারীর ক্যালেন্ডারে কোনো পরিবর্তন হলেই একটি নির্দিষ্ট কাজ সম্পাদন করা। এক্ষেত্রে একটি অনুচিত বিষয় হলো বারবার প্রতিটি প্রাসঙ্গিক ক্যালেন্ডার থেকে তথ্য সংগ্রহ করা। এর ফলে খুব দ্রুত আপনার সমস্ত কোটা শেষ হয়ে যাবে। উদাহরণস্বরূপ, যদি আপনার অ্যাপ্লিকেশনে ৫,০০০ ব্যবহারকারী থাকে এবং এটি প্রতি মিনিটে প্রত্যেক ব্যবহারকারীর ক্যালেন্ডার থেকে তথ্য সংগ্রহ করে, তাহলে কোনো কাজ শুরু হওয়ার আগেই এর জন্য প্রতি মিনিটে কমপক্ষে ৫,০০০ কোটার প্রয়োজন হবে।
সার্ভার-সাইড অ্যাপ্লিকেশনগুলো পুশ নোটিফিকেশনের জন্য রেজিস্টার করতে পারে, যার মাধ্যমে কোনো গুরুত্বপূর্ণ ঘটনা ঘটলে আমরা আপনাকে জানাতে পারি। এগুলো সেট আপ করতে কিছুটা বেশি পরিশ্রম করতে হয়, কিন্তু এর ফলে আপনার কোটা অনেক বেশি দক্ষতার সাথে ব্যবহার করা যায় এবং ব্যবহারকারীর অভিজ্ঞতাও উন্নত হয়। আপনি যে ইভেন্টের জন্য বিজ্ঞপ্তি পেতে চান, তার eventType অবশ্যই উল্লেখ করবেন। আরও তথ্যের জন্য, পুশ নোটিফিকেশন (Push notifications) দেখুন।
পরিষেবা অ্যাকাউন্টগুলির সাথে যথাযথ বরাদ্দ
যদি আপনার অ্যাপ্লিকেশনটি ডোমেন-ব্যাপী ডেলিগেশন ব্যবহার করে অনুরোধ সম্পাদন করে, তাহলে ডিফল্টরূপে আপনি যে ব্যবহারকারীকে ইমপারসোনেট করছেন তার পরিবর্তে সার্ভিস অ্যাকাউন্টকে "প্রতি মিনিট প্রতি ব্যবহারকারী প্রতি প্রজেক্ট" কোটার ভিত্তিতে চার্জ করা হয়। এর মানে হলো, সার্ভিস অ্যাকাউন্টটি একাধিক ব্যবহারকারীর ক্যালেন্ডারে কাজ করলেও, এর কোটা ফুরিয়ে যাওয়ার এবং রেট-লিমিটেড হওয়ার সম্ভাবনা থাকে।
কোন ব্যবহারকারীর কাছ থেকে চার্জ নেওয়া হবে তা নির্দেশ করতে আপনি quotaUser URL প্যারামিটার (অথবা x-goog-quota-user HTTP হেডার) ব্যবহার করে এটি এড়াতে পারেন। এটি শুধুমাত্র কোটা গণনার জন্য ব্যবহৃত হয়। আরও তথ্যের জন্য, `Limiting requests per user` দেখুন।
পরীক্ষার কোটা সীমা পরিচালনা
আপনার অ্যাপ্লিকেশনটি বাস্তবে কোটার সীমায় পৌঁছানোকে (উদাহরণস্বরূপ, এক্সপোনেনশিয়াল ব্যাকঅফ সহ রিট্রাইয়ের মাধ্যমে) সুষ্ঠুভাবে সামলাতে পারে কিনা তা নিশ্চিত করতে এবং আপনার ব্যবহারকারীদের সম্ভাব্য অসুবিধা কমাতে, আমরা একটি বাস্তব পরিবেশে আপনার সিনারিওটি পরীক্ষা করার জন্য দৃঢ়ভাবে সুপারিশ করছি।
আপনার আসল অ্যাপ্লিকেশন ব্যবহারে কোনো রকম হস্তক্ষেপ ছাড়াই পরীক্ষা করার জন্য, আমরা গুগল ক্লাউড কনসোলে একটি আলাদা শুধুমাত্র-পরীক্ষামূলক প্রজেক্ট রেজিস্টার করার এবং তারপর আপনার প্রোডাকশন প্রজেক্টের মতোই OAuth কনসেন্ট স্ক্রিনটি কনফিগার করার পরামর্শ দিই। এরপর আপনি এই প্রজেক্টটির জন্য কৃত্রিমভাবে কম কোটা সীমা নির্ধারণ করতে পারেন এবং আপনার অ্যাপ্লিকেশনের আচরণ পর্যবেক্ষণ করতে পারেন।