কোটা এবং সীমা

এই পৃষ্ঠায় Blaze pay-as-you-go মূল্য পরিকল্পনা অনুসারে Cloud Functions জন্য স্কেলেবল, ব্যবহার-ভিত্তিক সীমা সম্পর্কে বিস্তারিত বলা হয়েছে। এই সীমাগুলি Firebase প্রকল্পগুলির ক্ষেত্রে প্রযোজ্য যা Node.js 10 রানটাইম পরিবেশে ফাংশন স্থাপন করে।

ব্লেজ প্ল্যানটি প্রচুর পরিমাণে ইনভোকেশন, কম্পিউট টাইম এবং ইন্টারনেট ট্র্যাফিক বিনামূল্যে প্রদান করে। তবে, ফাংশন স্থাপনের জন্য ফাংশনের কন্টেইনারের জন্য ব্যবহৃত স্টোরেজ স্পেসের জন্য ছোট আকারের চার্জ প্রযোজ্য। আরও তথ্যের জন্য Firebase FAQ দেখুন।

Firebase জন্য কোটা ৪টি ক্ষেত্রকে অন্তর্ভুক্ত করে:

  • সম্পদের সীমা

    এগুলো আপনার ফাংশনগুলি যে পরিমাণ সম্পদ ব্যবহার করতে পারে তার মোট পরিমাণকে প্রভাবিত করে।

  • সময় সীমা

    এগুলো কতক্ষণ চলতে পারে তার উপর প্রভাব ফেলে।

  • হারের সীমা

    এগুলো আপনার ফাংশন পরিচালনা করার জন্য Firebase API-এ কল করার হারকে প্রভাবিত করে।

  • নেটওয়ার্কিং সীমা

    এগুলো আউটবাউন্ড সংযোগ এবং উদাহরণ সীমাকে প্রভাবিত করে।

বিভিন্ন ধরণের সীমা সম্পর্কে নিচে আরও বিস্তারিতভাবে বর্ণনা করা হয়েছে। প্রযোজ্য ক্ষেত্রে Firebase (1st gen) এবং Firebase (2nd gen) এর সীমার মধ্যে পার্থক্য উল্লেখ করা হয়েছে।

সম্পদের সীমা

সম্পদের সীমা আপনার ফাংশনগুলি কত পরিমাণ সম্পদ ব্যবহার করতে পারে তা প্রভাবিত করে। আঞ্চলিক পরিধি প্রতিটি প্রকল্পের জন্য, এবং প্রতিটি প্রকল্প তার নিজস্ব সীমা বজায় রাখে।

কোটা বিবরণ সীমা (প্রথম প্রজন্ম) সীমা (দ্বিতীয় প্রজন্ম) বাড়ানো যেতে পারে ব্যাপ্তি
ফাংশনের সংখ্যা প্রতি অঞ্চলে স্থাপন করা যেতে পারে এমন ফাংশনের মোট সংখ্যা ১,০০০ মোতায়েন করা Cloud Run পরিষেবার সংখ্যা বাদ দিয়ে ১,০০০ না অঞ্চল প্রতি
সর্বোচ্চ স্থাপনার আকার একটি একক ফাংশন স্থাপনের সর্বোচ্চ আকার উৎসের জন্য ১০০ এমবি (সংকুচিত)।
সোর্স প্লাস মডিউলের জন্য ৫০০MB (অসংকুচিত)।		 নিষিদ্ধ না প্রতি ফাংশন
সর্বাধিক আনকম্প্রেসড HTTP অনুরোধের আকার HTTP অনুরোধে HTTP ফাংশনে পাঠানো ডেটা ১০ এমবি ৩২ এমবি না প্রতি আহ্বানে
সর্বাধিক আনকম্প্রেসড HTTP প্রতিক্রিয়া আকার HTTP প্রতিক্রিয়ায় HTTP ফাংশন থেকে পাঠানো ডেটা ১০ এমবি স্ট্রিমিং প্রতিক্রিয়ার জন্য ১০MB।
নন-স্ট্রিমিং প্রতিক্রিয়ার জন্য 32MB।		 না প্রতি আহ্বানে
ইভেন্ট-চালিত ফাংশনের জন্য সর্বোচ্চ ইভেন্টের আকার ইভেন্টের ডেটা ব্যাকগ্রাউন্ড ফাংশনে পাঠানো হয়েছে ১০ এমবি Eventarc ইভেন্টের জন্য 512KB।
লিগ্যাসি ইভেন্টের জন্য ১০MB।		 না প্রতি ইভেন্টে
সর্বোচ্চ ফাংশন মেমোরি প্রতিটি ফাংশন ইনস্ট্যান্স কত মেমোরি ব্যবহার করতে পারে ৮ গিগাবাইট ৩২ গিগাবাইট না প্রতি ফাংশন
সর্বোচ্চ প্রকল্প মেমোরি একটি প্রকল্প কত মেমোরি ব্যবহার করতে পারে, By তে। এটি ১ মিনিটের সময়কালে ফাংশন ইনস্ট্যান্স জুড়ে ব্যবহারকারীর অনুরোধ করা মেমোরির মোট যোগফল দ্বারা পরিমাপ করা হয়। নির্বাচিত অঞ্চলের উপর নির্ভর করে। উচ্চ-ক্ষমতাসম্পন্ন অঞ্চলে এই সীমা বেশি বা সম্প্রতি খোলা অঞ্চলগুলিতে কম হতে পারে। নিষিদ্ধ হাঁ প্রকল্প এবং অঞ্চল প্রতি
সর্বোচ্চ প্রকল্প সিপিইউ একটি প্রকল্পে ব্যবহৃত CPU-র পরিমাণ, মিলি vCPU-তে। এটি ১ মিনিটের মধ্যে ফাংশন ইনস্ট্যান্স জুড়ে ব্যবহারকারীর অনুরোধকৃত CPU-এর মোট যোগফল দিয়ে পরিমাপ করা হয়। নির্বাচিত অঞ্চলের উপর নির্ভর করে। উচ্চ-ক্ষমতাসম্পন্ন অঞ্চলে এই সীমা বেশি বা সম্প্রতি খোলা অঞ্চলগুলিতে কম হতে পারে। নিষিদ্ধ হাঁ প্রকল্প এবং অঞ্চল প্রতি

সময় সীমা

কোটা বিবরণ সীমা (প্রথম প্রজন্ম) সীমা (দ্বিতীয় প্রজন্ম) বাড়ানো যেতে পারে ব্যাপ্তি
সর্বোচ্চ ফাংশন সময়কাল জোরপূর্বক বন্ধ করার আগে একটি ফাংশন সর্বোচ্চ কত সময় চলতে পারে ৫৪০ সেকেন্ড HTTP ফাংশনের জন্য ৬০ মিনিট।
ইভেন্ট-চালিত ফাংশনের জন্য ৬০ মিনিট।		 না প্রতি আহ্বানে

হারের সীমা

কোটা বিবরণ সীমা (প্রথম প্রজন্ম) সীমা (দ্বিতীয় প্রজন্ম) বাড়ানো যেতে পারে ব্যাপ্তি
API কল (READ) Firebase API এর মাধ্যমে ফাংশন বর্ণনা বা তালিকাভুক্ত করার জন্য কল করা হয় প্রতি ১০০ সেকেন্ডে ৫০০০ প্রতি ৬০ সেকেন্ডে ১২০০ শুধুমাত্র প্রথম প্রজন্মের জন্য প্রতি প্রকল্প (প্রথম প্রজন্ম)
অঞ্চল প্রতি (দ্বিতীয় প্রজন্ম)
API কল (WRITE) Firebase API এর মাধ্যমে ফাংশন স্থাপন বা মুছে ফেলার জন্য কল প্রতি ১০০ সেকেন্ডে ৮০ ৬০ সেকেন্ডে ৬০ নং ১ প্রতি প্রকল্প (প্রথম প্রজন্ম)
অঞ্চল প্রতি (দ্বিতীয় প্রজন্ম)
API কল (কল) "কল" API-তে কল প্রতি ১০০ সেকেন্ডে ১৬ নিষিদ্ধ নং ২ প্রতি প্রকল্পে

নেটওয়ার্কিং সীমা

Firebase (দ্বিতীয় প্রজন্ম) নেটওয়ার্কিং অনুরোধ এবং ব্যান্ডউইথ সীমা সম্পর্কে তথ্যের জন্য, নেটওয়ার্কিং সীমা দেখুন।

নিম্নলিখিত নেটওয়ার্কিং সীমাগুলি Firebase (প্রথম প্রজন্ম) এর ক্ষেত্রে প্রযোজ্য:

  • প্রতি সেকেন্ডে আউটবাউন্ড সংযোগ: ৫০০ (বাড়ানো যাবে না)
  • প্রতি সেকেন্ডে প্রতি উদাহরণে আউটবাউন্ড DNS রেজোলিউশন: ১০০ (বাড়ানো যাবে না)
  • প্রতি সেকেন্ডে সর্বোচ্চ প্যাকেট: ৮০,০০০
  • প্রতি সেকেন্ডে সর্বোচ্চ বিট: ১০০,০০০,০০০

স্কেলেবিলিটি

HTTP দ্বারা ব্যবহৃত Firebase দ্রুত স্কেল বৃদ্ধি করে যাতে আগত ট্র্যাফিক পরিচালনা করা যায়, অন্যদিকে ব্যাকগ্রাউন্ড ফাংশনগুলি ধীরে ধীরে স্কেল হয়। একটি ফাংশনের স্কেল বৃদ্ধির ক্ষমতা কয়েকটি বিষয় দ্বারা নির্ধারিত হয়, যার মধ্যে রয়েছে:

  • একটি ফাংশনের এক্সিকিউশন সম্পূর্ণ হতে কত সময় লাগে (স্বল্প-সময়ের ফাংশনগুলি সাধারণত আরও সমসাময়িক অনুরোধ পরিচালনা করার জন্য স্কেল করতে পারে)।
  • কোল্ড স্টার্টে একটি ফাংশন শুরু হতে যে পরিমাণ সময় লাগে।
  • আপনার ফাংশনের ত্রুটির হার।

  • ক্ষণস্থায়ী কারণ, যেমন আঞ্চলিক লোড এবং ডেটা সেন্টারের ক্ষমতা।

ব্যাকগ্রাউন্ড ফাংশনের অতিরিক্ত সীমা রয়েছে, যা নিচে ব্যাখ্যা করা হয়েছে। এই সীমাগুলি প্রথম প্রজন্মের HTTP ফাংশনের ক্ষেত্রে প্রযোজ্য নয়।

ব্যাকগ্রাউন্ড ফাংশনের জন্য অতিরিক্ত কোটা

কোটা বিবরণ সীমা বাড়ানো যেতে পারে ব্যাপ্তি পণ্য সংস্করণ
সর্বাধিক সমসাময়িক আহ্বান একটি একক ফাংশনের সর্বাধিক সমবর্তী আহ্বান
উদাহরণ: যদি প্রতিটি ইভেন্ট পরিচালনা করতে ১০০ সেকেন্ড সময় লাগে, তাহলে আমন্ত্রণের হার গড়ে প্রতি সেকেন্ডে ৩০ সেকেন্ডে সীমাবদ্ধ থাকবে।		 ৩,০০০ হাঁ প্রতি ফাংশন শুধুমাত্র প্রথম প্রজন্মের জন্য
সর্বোচ্চ আহ্বানের হার একটি একক ফাংশন দ্বারা পরিচালিত ইভেন্টের সর্বোচ্চ হার
উদাহরণ: যদি কোনও ইভেন্ট পরিচালনা করতে ১০০ মিলিসেকেন্ড সময় লাগে, তাহলে আমন্ত্রণের হার প্রতি সেকেন্ডে ১০০০-এর মধ্যে সীমাবদ্ধ থাকবে, এমনকি যদি গড়ে মাত্র ১০০টি অনুরোধ সমান্তরালভাবে পরিচালনা করা হয়।		 প্রতি সেকেন্ডে ১০০০ না প্রতি ফাংশন শুধুমাত্র প্রথম প্রজন্মের জন্য
সর্বাধিক সমসাময়িক ইভেন্ট ডেটার আকার একটি একক ফাংশনের সমসাময়িক আহ্বানের সাথে আগত ইভেন্টের সর্বাধিক মোট আকার
উদাহরণ: যদি ইভেন্টগুলি ১ মেগাবাইট আকারের হয় এবং সেগুলি প্রক্রিয়া করতে ১০ সেকেন্ড সময় লাগে, তাহলে গড় হার হবে প্রতি সেকেন্ডে ১টি ইভেন্ট, কারণ প্রথম ১০টি ইভেন্টের একটি প্রক্রিয়াকরণ শেষ না হওয়া পর্যন্ত ১১তম ইভেন্টটি প্রক্রিয়া করা হবে না।		 ১০ এমবি না প্রতি ফাংশন প্রথম প্রজন্ম এবং দ্বিতীয় প্রজন্ম
ইনকামিং ইভেন্টের সর্বোচ্চ থ্রুপুট একটি একক ফাংশনে আগত ইভেন্টের সর্বাধিক থ্রুপুট
উদাহরণ: যদি ইভেন্টের আকার ১ এমবি হয়, তাহলে ইনভোকেশন রেট প্রতি সেকেন্ডে সর্বোচ্চ ১০ হতে পারে, এমনকি যদি ফাংশন ১০০ মিলিসেকেন্ডের মধ্যে শেষ হয়।		 প্রতি সেকেন্ডে ১০ এমবি না প্রতি ফাংশন প্রথম প্রজন্ম এবং দ্বিতীয় প্রজন্ম

যখন আপনি কোটার সীমায় পৌঁছাবেন

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

এখানে তালিকাভুক্ত ডিফল্টের উপরে কোটা বাড়াতে, Firebase কোটা পৃষ্ঠায় যান, আপনি যে কোটাগুলি পরিবর্তন করতে চান তা নির্বাচন করুন, Edit quotas এ ক্লিক করুন, অনুরোধ করা হলে আপনার ব্যবহারকারীর তথ্য সরবরাহ করুন এবং আপনার নির্বাচিত প্রতিটি কোটার জন্য নতুন কোটা সীমা লিখুন।

Firebase CLI স্থাপনার জন্য কোটার সীমা

Firebase CLI যে প্রতিটি ফাংশন স্থাপন করে, তার জন্য এই ধরণের হার এবং সময়সীমা প্রভাবিত হয়:

  • API কল (READ) - প্রতি স্থাপনার জন্য ১টি কল, যত ফাংশনই থাকুক না কেন
    • সীমা: প্রতি ১০০ সেকেন্ডে ৫০০০
  • API কল (WRITE) - প্রতি ফাংশনে ১টি কল
    • সীমা: প্রতি ১০০ সেকেন্ডে ৮০

ফায়ারবেস সিএলআই রেফারেন্সটিও দেখুন।