আমরা বর্তমানে অফলাইন থেকে তাত্ক্ষণিক প্রতিবেদনে প্রতিবেদনের প্রকারের একটি উপসেট স্থানান্তর করছি৷ একবার একজন ব্যবহারকারী স্থানান্তরিত হলে, queries.list প্রতিক্রিয়া বিদ্যমান তাত্ক্ষণিক প্রতিবেদন অন্তর্ভুক্ত করবে। আরো তথ্যের জন্য আমাদের ব্লগ পোস্ট দেখুন.

এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

কোটা

কোটাগুলি Google এর পরিকাঠামোকে স্বয়ংক্রিয় প্রক্রিয়া থেকে রক্ষা করে যা Google Bid Manager API ব্যবহার করে একটি অনুপযুক্ত উপায়ে। তারা নিশ্চিত করে যে একজন বিকাশকারীর ক্রিয়াকলাপ বৃহত্তর সম্প্রদায়কে নেতিবাচকভাবে প্রভাবিত করতে পারে না।

কোটার সীমা

নিম্নলিখিত ডিফল্ট কোটা সীমা সমস্ত বিড ম্যানেজার API সংস্থান এবং পদ্ধতি দ্বারা ভাগ করা হয়৷

প্রকল্প প্রতি প্রতিদিন 2,000 অনুরোধ - বাড়ানো যেতে পারে ।
প্রতি সেকেন্ডে 4টি প্রশ্ন (QPS) প্রতি প্রকল্প।
- Google API কনসোলে এই কোটাটিকে প্রতি মিনিটে প্রতি ব্যবহারকারীর প্রশ্ন হিসাবে উল্লেখ করা হয় এবং 240-এ সেট করা হয়।

কোটার সীমা অতিক্রম করছে

কোটা সীমা অতিক্রম করার কারণে আপনার অনুরোধ ব্যর্থ হওয়ার সম্ভাবনা কম হলে, API একটি HTTP স্ট্যাটাস কোড এবং ত্রুটির কারণ প্রদান করে। উপরন্তু, প্রতিক্রিয়ার মূল অংশে ত্রুটির কারণের একটি বিশদ বিবরণ রয়েছে। একটি উদাহরণ ত্রুটি প্রতিক্রিয়া জন্য ত্রুটি বার্তা নির্দেশিকা দেখুন.

নিম্নলিখিত তালিকাটি কোটা সীমা অতিক্রম করার কারণে অনুরোধ ব্যর্থতার জন্য সম্ভাব্য ত্রুটি এবং সুপারিশকৃত পদক্ষেপগুলি দেখায়।

কোড	কারণ	বার্তা	সুপারিশকৃত কাজ
403	দৈনিক সীমা ছাড়িয়ে গেছে	দৈনিক সীমা ছাড়িয়ে গেছে	সমস্যার সমাধান না করে আবার চেষ্টা করবেন না। Google API কনসোল থেকে আপনার ব্যবহার পরীক্ষা করুন এবং কম অনুরোধ করতে আপনার কর্মপ্রবাহ পরিবর্তন করুন। আপনি অতিরিক্ত কোটার অনুরোধ করতে পারেন যদি আপনি বিশ্বাস করেন যে আপনার ব্যবহার যুক্তিসঙ্গত।
403	userRate LimitExeded	ব্যবহারকারীর হার সীমা অতিক্রম করেছে৷	সূচকীয় ব্যাকঅফ ব্যবহার করে আপনি যে হারে অনুরোধ পাঠাচ্ছেন সেটির গতি কমিয়ে দিন।

সূচকীয় ব্যাকঅফ কি?

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

সঠিকভাবে ব্যবহার করা হলে, সূচকীয় ব্যাকঅফ ব্যান্ডউইথ ব্যবহারের দক্ষতা বাড়ায়, সফল প্রতিক্রিয়া পাওয়ার জন্য প্রয়োজনীয় অনুরোধের সংখ্যা হ্রাস করে এবং সমসাময়িক পরিবেশে অনুরোধের থ্রুপুট সর্বাধিক করে।

সাধারণ সূচকীয় ব্যাকঅফ বাস্তবায়নের জন্য প্রবাহ নিম্নরূপ:

API এ একটি অনুরোধ করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
1 সেকেন্ড + random_number_milliseconds অপেক্ষা করুন এবং অনুরোধটি আবার চেষ্টা করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
2 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
4 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
8 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
একটি HTTP 503 প্রতিক্রিয়া পান, যা নির্দেশ করে যে আপনার অনুরোধটি পুনরায় চেষ্টা করা উচিত।
16 সেকেন্ড + এলোমেলো_সংখ্যা_মিলিসেকেন্ড অপেক্ষা করুন এবং অনুরোধটি পুনরায় চেষ্টা করুন।
থামো। একটি ত্রুটি রিপোর্ট বা লগ.

উপরের প্রবাহে, এলোমেলো_সংখ্যা_মিলিসেকেন্ড হল 1000 এর চেয়ে কম বা সমান মিলিসেকেন্ডের একটি এলোমেলো সংখ্যা। এটি প্রয়োজনীয়, যেহেতু একটি ছোট র্যান্ডম বিলম্ব প্রবর্তন লোডকে আরও সমানভাবে বিতরণ করতে সাহায্য করে এবং সার্ভারের স্ট্যাম্পিং হওয়ার সম্ভাবনা এড়াতে সাহায্য করে। এলোমেলো_সংখ্যা_মিলিসেকেন্ডের মান প্রতিটি অপেক্ষার পরে পুনরায় সংজ্ঞায়িত করা আবশ্যক।

দ্রষ্টব্য: অপেক্ষা সর্বদা (2 ^ n) + এলোমেলো_সংখ্যা_মিলিসেকেন্ড, যেখানে n হল একটি একঘেয়ে ক্রমবর্ধমান পূর্ণসংখ্যা যা প্রাথমিকভাবে 0 হিসাবে সংজ্ঞায়িত করা হয়। প্রতিটি পুনরাবৃত্তির (প্রতিটি অনুরোধ) জন্য পূর্ণসংখ্যা 1 দ্বারা বৃদ্ধি করা হয়।

n 5 হলে অ্যালগরিদম শেষ হতে সেট করা হয়। এই সিলিং ক্লায়েন্টদের অসীমভাবে পুনরায় চেষ্টা করতে বাধা দেয় এবং একটি অনুরোধ "একটি পুনরুদ্ধারযোগ্য ত্রুটি" বলে গণ্য হওয়ার আগে প্রায় 32 সেকেন্ডের মোট বিলম্ব হয়। একটি বৃহত্তর সর্বাধিক সংখ্যক পুনঃপ্রয়াস ঠিক আছে, বিশেষ করে যদি একটি দীর্ঘ আপলোড চলছে; শুধু যুক্তিসঙ্গত কিছুতে পুনঃপ্রচেষ্টা বিলম্ব ক্যাপ করতে ভুলবেন না, বলুন, এক মিনিটেরও কম।

অতিরিক্ত দৈনিক কোটা অনুরোধ করা হচ্ছে

আপনি যদি মনে করেন যে আপনার আবেদনের জন্য অতিরিক্ত দৈনিক কোটার প্রয়োজন, আপনি নীচের নির্দেশাবলী অনুসরণ করে আরও অনুরোধ করতে পারেন।

নিম্নলিখিত নির্দেশাবলী শুধুমাত্র সেই প্রকল্পগুলির জন্য প্রযোজ্য যেগুলি একটি dailyLimitExceeded ত্রুটির সম্মুখীন হয়েছে৷ অন্যান্য কোটা ত্রুটির জন্য প্রস্তাবিত পদক্ষেপগুলি উপরের টেবিলে কভার করা হয়েছে৷

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

তথ্য পর্যালোচনা করা নিশ্চিত করুন এবং একটি বৃদ্ধির অনুরোধ জমা দেওয়ার আগে কোটা অনুরোধ ফর্মে অন্তর্ভুক্ত নির্দেশাবলী অনুসরণ করুন।