কোটা নীতি

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

কী

একটি এপিআই প্রক্সি নির্দিষ্ট সময়কালে (যেমন মিনিট, ঘন্টা, দিন, সপ্তাহ বা মাস) কতগুলো অনুরোধ বার্তা গ্রহণ করবে, তা নির্ধারণ করতে কোটা নীতি ব্যবহার করুন। আপনি এপিআই প্রক্সি অ্যাক্সেসকারী সমস্ত অ্যাপের জন্য কোটা একই রাখতে পারেন, অথবা নিম্নলিখিত বিষয়গুলোর উপর ভিত্তি করে কোটা নির্ধারণ করতে পারেন:

• যে পণ্যটিতে এপিআই প্রক্সি রয়েছে
• এপিআই-এর জন্য অনুরোধকারী অ্যাপটি
• অ্যাপ ডেভেলপার
• আরও অনেক মানদণ্ড

সামগ্রিক ট্র্যাফিক স্পাইক থেকে সুরক্ষা পেতে কোটা ব্যবহার করবেন না। এর জন্য স্পাইক অ্যারেস্ট পলিসি ব্যবহার করুন। স্পাইক অ্যারেস্ট পলিসি দেখুন।

ভিডিও

এই ভিডিওগুলিতে কোটা নীতির মাধ্যমে কোটা ব্যবস্থাপনার সাথে পরিচয় করিয়ে দেওয়া হয়েছে:

নমুনা

এই নীতি কোডের নমুনাগুলো নিম্নোক্ত উপায়ে কোটার মেয়াদ শুরু ও শেষ করার পদ্ধতি ব্যাখ্যা করে:

<Quota name="CheckQuota">
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

<Quota name="DeveloperQuota">
  <Identifier ref="verifyapikey.verify-api-key.client_id"/>
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/>
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/>
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/>
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2017-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<AssignMessage async="false" continueOnError="false" enabled="true" name="ReturnQuotaVars">
    <AssignTo createNew="false" type="response"/>
    <Set>
        <Headers>
            <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
            <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
            <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/>
  <StartTime>2017-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Identifier ref="request.queryparam.id"/>

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

কোটা নীতি সম্পর্কে

কোটা হলো অনুরোধ বার্তার একটি বরাদ্দ, যা একটি এপিআই প্রক্সি একটি নির্দিষ্ট সময়কালে (যেমন মিনিট, ঘন্টা, দিন, সপ্তাহ বা মাস) পরিচালনা করতে পারে। এই পলিসি কাউন্টার বজায় রাখে যা এপিআই প্রক্সি দ্বারা প্রাপ্ত অনুরোধের সংখ্যা গণনা করে। এই ক্ষমতা এপিআই প্রোভাইডারদের একটি নির্দিষ্ট সময়সীমার মধ্যে অ্যাপ দ্বারা করা এপিআই কলের সংখ্যার উপর সীমা আরোপ করতে সক্ষম করে। কোটা পলিসি ব্যবহার করে আপনি, উদাহরণস্বরূপ, অ্যাপগুলিকে প্রতি মিনিটে ১টি অনুরোধ বা প্রতি মাসে ১০,০০০টি অনুরোধে সীমাবদ্ধ করতে পারেন।

উদাহরণস্বরূপ, যদি প্রতি মাসে ১০,০০০ মেসেজের একটি কোটা নির্ধারণ করা হয়, তবে ১০,০০০তম মেসেজের পর থেকে রেট-লিমিটিং শুরু হবে। ঐ নির্দিষ্ট সময়ের প্রথম দিনে বা শেষ দিনে ১০,০০০ মেসেজ গণনা করা হয়েছে কিনা, তা বিবেচ্য নয়; নির্দিষ্ট সময়সীমার শেষে কোটা কাউন্টারটি স্বয়ংক্রিয়ভাবে রিসেট না হওয়া পর্যন্ত, অথবা 'রিসেট কোটা পলিসি' ব্যবহার করে কোটা স্পষ্টভাবে রিসেট না করা পর্যন্ত কোনো অতিরিক্ত অনুরোধের অনুমতি দেওয়া হবে না।

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

কোটা প্রতিটি এপিআই প্রক্সির জন্য আলাদাভাবে প্রযোজ্য এবং এটি প্রক্সিগুলোর মধ্যে বন্টন করা হয় না। উদাহরণস্বরূপ, যদি আপনার একটি এপিআই প্রোডাক্টে তিনটি এপিআই প্রক্সি থাকে, তবে একটিমাত্র কোটা তিনটির মধ্যে ভাগ করা হয় না, এমনকি যদি তিনটিই একই কোটা পলিসি কনফিগারেশন ব্যবহার করে থাকে।

কোটা নীতির প্রকারভেদ

কোটা পলিসি বিভিন্ন ধরনের পলিসি সমর্থন করে: ডিফল্ট, calendar , flexi এবং rollingwindow । প্রতিটি ধরন নির্ধারণ করে দেয় কখন কোটা কাউন্টার শুরু হবে এবং কখন তা রিসেট হবে, যা নিচের সারণিতে দেখানো হয়েছে:

type="calendar" এর জন্য, আপনাকে অবশ্যই <StartTime> এর মান নির্দিষ্ট করতে হবে।

টেবিলে rollingwindow টাইপের জন্য মান তালিকাভুক্ত করা নেই। রোলিং উইন্ডো কোটা একটি কোটা "উইন্ডো"-এর আকার নির্ধারণের মাধ্যমে কাজ করে, যেমন এক ঘন্টা বা এক দিনের উইন্ডো। যখন একটি নতুন অনুরোধ আসে, তখন পলিসি নির্ধারণ করে যে বিগত "উইন্ডো" সময়ের মধ্যে কোটা অতিক্রম করা হয়েছে কি না।

উদাহরণস্বরূপ, আপনি দুই ঘণ্টার একটি সময়সীমা নির্ধারণ করেছেন যা ১০০০টি অনুরোধের অনুমতি দেয়। বিকেল ৪:৪৫ মিনিটে একটি নতুন অনুরোধ আসে। পলিসিটি বিগত দুই ঘণ্টার জন্য কোটার সংখ্যা গণনা করে, অর্থাৎ দুপুর ২:৪৫ মিনিটের পর থেকে অনুরোধের সংখ্যা। যদি সেই দুই ঘণ্টার মধ্যে কোটার সীমা অতিক্রম না করা হয়, তাহলে অনুরোধটি অনুমোদিত হয়।

এক মিনিট পর, বিকেল ৪:৪৬ মিনিটে, আরেকটি অনুরোধ আসে। এখন সীমা অতিক্রম করা হয়েছে কিনা তা নির্ধারণ করার জন্য নীতিমালাটি দুপুর ২:৪৬ মিনিট থেকে কোটার সংখ্যা গণনা করে।

rollingwindow টাইপের ক্ষেত্রে, কাউন্টারটি কখনও রিসেট হয় না, বরং প্রতিটি অনুরোধে এটি পুনরায় গণনা করা হয়।

কোটা কাউন্টার বোঝা

ডিফল্টরূপে, একটি কোটা পলিসি একটিমাত্র কাউন্টার বজায় রাখে, আপনি একটি এপিআই প্রক্সিতে এটিকে যতবারই উল্লেখ করুন না কেন। কোটা কাউন্টারের নামটি পলিসির name অ্যাট্রিবিউটের উপর ভিত্তি করে নির্ধারিত হয়।

উদাহরণস্বরূপ, আপনি MyQuotaPolicy নামে ৫টি রিকোয়েস্টের সীমা সহ একটি কোটা পলিসি তৈরি করেন এবং এটিকে এপিআই প্রক্সির একাধিক ফ্লোতে (ফ্লো এ, বি, এবং সি) স্থাপন করেন। যদিও এটি একাধিক ফ্লোতে ব্যবহৃত হয়, এটি একটি একক কাউন্টার বজায় রাখে যা পলিসিটির সমস্ত ইনস্ট্যান্স দ্বারা আপডেট করা হয়:

• ফ্লো A সম্পাদিত হয় -> MyQuotaPolicy কার্যকর হয় এবং এর কাউন্টার = 1
• ফ্লো B কার্যকর করা হয়েছে -> MyQuotaPolicy কার্যকর করা হয়েছে এবং এর কাউন্টার = 2
• ফ্লো A কার্যকর করা হয়েছে -> MyQuotaPolicy কার্যকর করা হয়েছে এবং এর কাউন্টার = 3
• ফ্লো C কার্যকর করা হয়েছে -> MyQuotaPolicy কার্যকর করা হয়েছে এবং এর কাউন্টার = 4
• ফ্লো A সম্পাদিত হয়েছে -> MyQuotaPolicy কার্যকর হয়েছে এবং এর কাউন্টার = 5

তিনটি ফ্লো-এর যেকোনো একটিতে পরবর্তী অনুরোধটি প্রত্যাখ্যান করা হয়েছে, কারণ কোটা কাউন্টার তার সীমায় পৌঁছে গেছে।

একটি এপিআই প্রক্সি ফ্লো-তে একাধিক স্থানে একই কোটা পলিসি ব্যবহার করা, যা অনিচ্ছাকৃতভাবে আপনার প্রত্যাশার চেয়ে দ্রুত কোটা শেষ করে দিতে পারে, সেটি 'দ্য বুক অফ এপিজি এজ অ্যান্টিপ্যাটার্নস'- এ বর্ণিত একটি অ্যান্টি-প্যাটার্ন।

বিকল্পভাবে, আপনি আপনার এপিআই প্রক্সিতে একাধিক কোটা পলিসি নির্ধারণ করতে পারেন এবং প্রতিটি ফ্লোতে ভিন্ন পলিসি ব্যবহার করতে পারেন। প্রতিটি কোটা পলিসি তার name অ্যাট্রিবিউটের উপর ভিত্তি করে নিজস্ব কাউন্টার বজায় রাখে।

অথবা, একটিমাত্র পলিসিতে একাধিক ও স্বতন্ত্র কাউন্টার নির্ধারণ করতে কোটা পলিসিতে <Class> বা <Identifier> এলিমেন্ট ব্যবহার করুন। এই এলিমেন্টগুলো ব্যবহার করে, একটিমাত্র পলিসি অনুরোধকারী অ্যাপ, অনুরোধকারী অ্যাপ ডেভেলপার, একটি ক্লায়েন্ট আইডি বা অন্য কোনো ক্লায়েন্ট আইডেন্টিফায়ার এবং আরও অনেক কিছুর উপর ভিত্তি করে ভিন্ন ভিন্ন কাউন্টার বজায় রাখতে পারে। <Class> বা <Identifier> এলিমেন্ট ব্যবহারের বিষয়ে আরও তথ্যের জন্য উপরের উদাহরণগুলো দেখুন।

সময় সংকেত

সকল কোটার সময় কোঅর্ডিনেটেড ইউনিভার্সাল টাইম (UTC) সময় অঞ্চল অনুযায়ী নির্ধারণ করা হয়।

কোটা সময়ের সংকেত আন্তর্জাতিক মান ISO 8601- এ সংজ্ঞায়িত আন্তর্জাতিক মান তারিখ সংকেত পদ্ধতি অনুসরণ করে।

তারিখকে বছর, মাস এবং দিন দিয়ে YYYY-MM-DD বিন্যাসে সংজ্ঞায়িত করা হয়। উদাহরণস্বরূপ, 2015-02-04 বলতে 4 ফেব্রুয়ারী, 2015 বোঝায়।

দিনের সময়কে ঘন্টা, মিনিট এবং সেকেন্ড হিসাবে নিম্নলিখিত বিন্যাসে সংজ্ঞায়িত করা হয়: hours:minutes:seconds । উদাহরণস্বরূপ, 23:59:59 মধ্যরাতের এক সেকেন্ড আগের সময়কে বোঝায়।

উল্লেখ্য যে, একটি তারিখের সাথে সম্পর্কিত দুটি মধ্যরাত্রিকে আলাদা করার জন্য 00:00:00 এবং 24:00:00 , এই দুটি চিহ্ন ব্যবহার করা হয়। সুতরাং, 2015-02-04 24:00:00 এবং 2015-02-05 00:00:00 একই তারিখ ও সময়। সাধারণত শেষের চিহ্নটিই বেশি পছন্দ করা হয়।

এপিআই প্রোডাক্ট কনফিগারেশন থেকে কোটা সেটিংস পাওয়া

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

• এপিআই প্রোডাক্টের সমস্ত এপিআই প্রক্সিতে কোটা পলিসি একটি অভিন্ন সেটিং ব্যবহার করতে পারে।
• আপনি একটি এপিআই প্রোডাক্টের কোটা সেটিং-এ রানটাইম পরিবর্তন করতে পারেন, এবং যে কোটা পলিসিগুলো সেই মানটিকে উল্লেখ করে, সেগুলোর কোটার মান স্বয়ংক্রিয়ভাবে আপডেট হয়ে যায়।

একটি এপিআই প্রোডাক্ট থেকে কোটা সেটিংস ব্যবহার করার বিষয়ে আরও তথ্যের জন্য, উপরের 'ডাইনামিক কোটা' উদাহরণটি দেখুন ।

কোটা সীমা সহ এপিআই পণ্য কনফিগার করার তথ্যের জন্য, এপিআই পণ্য তৈরি করুন দেখুন।

উপাদান রেফারেন্স

এই পলিসিতে আপনি নিম্নলিখিত উপাদান এবং অ্যাট্রিবিউটগুলো কনফিগার করতে পারেন। মনে রাখবেন যে কিছু উপাদানের সংমিশ্রণ পরস্পর বর্জনীয় বা আবশ্যক নয়। নির্দিষ্ট ব্যবহারের জন্য নমুনাগুলো দেখুন। যখন অনুরোধে অ্যাপের এপিআই কী যাচাই করার জন্য "VerifyAPIKey" নামক একটি ভেরিফাই এপিআই কী পলিসি ব্যবহার করা হয়, তখন নিচের verifyapikey.VerifyAPIKey.apiproduct.* ভেরিয়েবলগুলো ডিফল্টরূপে উপলব্ধ থাকে। ভেরিয়েবলের মানগুলো সেই এপিআই প্রোডাক্টের কোটা সেটিংস থেকে আসে যার সাথে কী-টি যুক্ত, যেমনটি "এপিআই প্রোডাক্ট কনফিগারেশন থেকে কোটা সেটিংস পাওয়া" অংশে বর্ণনা করা হয়েছে।

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="5000"/>
        <Allow class="off_peak_time" count="1000"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
   <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2017-7-16 12:00:00</StartTime>
   <Distributed>false</Distributed>
   <Synchronous>false</Synchronous>
   <AsynchronousConfiguration>
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
      <SyncMessageCount>5</SyncMessageCount>
   </AsynchronousConfiguration>
   <Identifier/>
   <MessageWeight/>
</Quota>

<কোটা> বৈশিষ্ট্য

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">

নিম্নলিখিত বৈশিষ্ট্যগুলো এই পলিসির জন্য নির্দিষ্ট।

নিম্নলিখিত সারণী সমস্ত নীতির মূল উপাদানগুলির জন্য সাধারণ বৈশিষ্ট্যগুলি বর্ণনা করে:

<DisplayName> উপাদান

ম্যানেজমেন্ট UI প্রক্সি এডিটরে নীতিটিকে একটি ভিন্ন, প্রাকৃতিক-ভাষা নামের সাথে লেবেল করতে name বৈশিষ্ট্য ছাড়াও ব্যবহার করুন।

<DisplayName>Policy Display Name</DisplayName>

<Allow> উপাদান

কোটার জন্য গণনার সীমা নির্দিষ্ট করে। যদি পলিসির কাউন্টারটি এই নির্ধারিত সীমায় পৌঁছে যায়, তবে কাউন্টারটি রিসেট না হওয়া পর্যন্ত পরবর্তী কলগুলো প্রত্যাখ্যান করা হয়।

নিচে <Allow> এলিমেন্টটি সেট করার তিনটি উপায় দেখানো হলো:

<Allow count="2000"/>

<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

যদি আপনি count এবং countRef উভয়ই উল্লেখ করেন, তাহলে countRef অগ্রাধিকার পাবে। যদি রানটাইমে countRef নির্ধারিত না হয়, তাহলে count এর মান ব্যবহৃত হবে।

বৈশিষ্ট্য

<Allow>/<Class> উপাদান

<Class> এলিমেন্টটি আপনাকে একটি ফ্লো ভ্যারিয়েবলের মানের উপর ভিত্তি করে <Allow> এলিমেন্টের মান শর্তসাপেক্ষ করার সুযোগ দেয়। <Class> এর প্রতিটি ভিন্ন <Allow> চাইল্ড ট্যাগের জন্য, পলিসিটি একটি ভিন্ন কাউন্টার বজায় রাখে।

<Class> এলিমেন্টটি ব্যবহার করতে, <Class> ট্যাগের ref অ্যাট্রিবিউটের মাধ্যমে একটি ফ্লো ভ্যারিয়েবল নির্দিষ্ট করুন। এরপর Edge সেই ফ্লো ভ্যারিয়েবলের মান ব্যবহার করে পলিসির অনুমোদিত সংখ্যা নির্ধারণ করার জন্য <Allow> চাইল্ড ট্যাগগুলোর মধ্যে একটিকে নির্বাচন করে। Edge ফ্লো ভ্যারিয়েবলের মানটিকে <Allow> ট্যাগের class অ্যাট্রিবিউটের সাথে মিলিয়ে দেখে, যেমনটি নিচে দেখানো হয়েছে:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

এই উদাহরণে, প্রতিটি অনুরোধের সাথে পাঠানো time_variable কোয়েরি প্যারামিটারের মান দ্বারা বর্তমান কোটা কাউন্টার নির্ধারিত হয়। সেই ভেরিয়েবলটির মান peak_time বা off_peak_time হতে পারে। যদি কোয়েরি প্যারামিটারটিতে কোনো অবৈধ মান থাকে, তাহলে পলিসিটি একটি কোটা লঙ্ঘনের ত্রুটি ফেরত দেয়।

বৈশিষ্ট্য

<Allow>/<Class>/<Allow> এলিমেন্ট

<Allow> এলিমেন্টটি <Class> এলিমেন্ট দ্বারা সংজ্ঞায়িত একটি কোটা কাউন্টারের সীমা নির্দিষ্ট করে। <Class> এর প্রতিটি ভিন্ন <Allow> চাইল্ড ট্যাগের জন্য, পলিসিটি একটি ভিন্ন কাউন্টার বজায় রাখে।

উদাহরণস্বরূপ:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

এই উদাহরণে, কোটা পলিসিটি peak_time এবং off_peak_time নামে দুটি কোটা কাউন্টার বজায় রাখে।

বৈশিষ্ট্য

<Interval> উপাদান

একটি পূর্ণসংখ্যা (যেমন, ১, ২, ৫, ৬০, ইত্যাদি) নির্দিষ্ট করতে এটি ব্যবহার করুন, যা আপনার নির্দিষ্ট করা TimeUnit (মিনিট, ঘন্টা, দিন, সপ্তাহ বা মাস) সাথে যুক্ত হয়ে একটি সময়কাল নির্ধারণ করবে, যে সময়ের মধ্যে Edge কোটা ব্যবহারের হিসাব করবে।

উদাহরণস্বরূপ, hour TimeUnit সহ একটি 24 এর Interval অর্থ হলো, কোটাটি ২৪ ঘন্টা ধরে গণনা করা হবে।

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>

বৈশিষ্ট্য

<TimeUnit> উপাদান

কোটার জন্য প্রযোজ্য সময়ের একক নির্দিষ্ট করতে ব্যবহার করুন।

উদাহরণস্বরূপ, hour TimeUnit সহ একটি 24 এর Interval অর্থ হলো, কোটাটি ২৪ ঘন্টা ধরে গণনা করা হবে।

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>

বৈশিষ্ট্য

<শুরুর সময়> উপাদান

type calendar, এটি সেই তারিখ ও সময় নির্দিষ্ট করে যখন কোটা কাউন্টার গণনা শুরু করবে, কোনো অ্যাপ থেকে কোনো অনুরোধ এসেছে কি না তা নির্বিশেষে।

উদাহরণস্বরূপ:

<StartTime>2017-7-16 12:00:00</StartTime>

<বিতরণকৃত> উপাদান

Edge-এর একটি ইনস্টলেশন অনুরোধগুলি প্রক্রিয়া করার জন্য এক বা একাধিক মেসেজ প্রসেসর ব্যবহার করতে পারে। পলিসিটি যেন একটি কেন্দ্রীয় কাউন্টার বজায় রাখে এবং সমস্ত মেসেজ প্রসেসর জুড়ে এটিকে ক্রমাগত সিঙ্ক্রোনাইজ করে, তা নির্দিষ্ট করতে এই উপাদানটিকে ' true তে সেট করুন। মেসেজ প্রসেসরগুলি অ্যাভেইলেবিলিটি জোন এবং/অথবা রিজিয়ন জুড়ে থাকতে পারে।

আপনি যদি ' false ' ডিফল্ট মানটি ব্যবহার করেন, তাহলে আপনার কোটা অতিক্রম করার সম্ভাবনা রয়েছে, কারণ প্রতিটি মেসেজ প্রসেসরের জন্য নির্ধারিত সংখ্যা ভাগ করা হয় না:

<Distributed>true</Distributed>

কাউন্টারগুলো যেন সিঙ্ক্রোনাইজড থাকে এবং প্রতিটি অনুরোধে আপডেট হয়, তা নিশ্চিত করতে <Distributed> এবং <Synchronous> কে true তে সেট করুন:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>

<সিঙ্ক্রোনাস> উপাদান

একটি ডিস্ট্রিবিউটেড কোটা কাউন্টার সিনক্রোনাসভাবে আপডেট করতে এটিকে ' true সেট করুন। এর মানে হলো, এপিআই-তে কোনো অনুরোধের মাধ্যমে কোটা যাচাই করার সময়েই কাউন্টারটি আপডেট করা হয়। যদি কোটার বাইরে কোনো এপিআই কল অনুমোদন না করা অপরিহার্য হয়, তবে এটিকে ' true সেট করুন।

কোটা কাউন্টারটি অ্যাসিঙ্ক্রোনাসভাবে আপডেট করতে এটিকে 'ফলস' ( false সেট করুন। এর মানে হলো, সেন্ট্রাল রিপোজিটরিতে কোটা কাউন্টারটি কখন অ্যাসিঙ্ক্রোনাসভাবে আপডেট করা হচ্ছে তার উপর নির্ভর করে, কোটা অতিক্রমকারী কিছু এপিআই কল সফল হওয়ার সম্ভাবনা রয়েছে। তবে, সিঙ্ক্রোনাস আপডেটের সাথে সম্পর্কিত সম্ভাব্য পারফরম্যান্সের প্রভাব আপনাকে মোকাবেলা করতে হবে না।

ডিফল্ট অ্যাসিঙ্ক্রোনাস আপডেট ব্যবধান হলো ১০ সেকেন্ড। এই অ্যাসিঙ্ক্রোনাস আচরণটি কনফিগার করতে AsynchronousConfiguration এলিমেন্টটি ব্যবহার করুন।

<Synchronous>false</Synchronous>

<অ্যাসিঙ্ক্রোনাস কনফিগারেশন> উপাদান

যখন পলিসি কনফিগারেশন এলিমেন্ট <Synchronous> অনুপস্থিত থাকে অথবা উপস্থিত থেকে false এ সেট করা থাকে, তখন ডিস্ট্রিবিউটেড কোটা কাউন্টারগুলোর মধ্যে সিনক্রোনাইজেশন ইন্টারভ্যাল কনফিগার করে।

আপনি SyncIntervalInSeconds অথবা SyncMessageCount চাইল্ড এলিমেন্টগুলো ব্যবহার করে একটি নির্দিষ্ট সময় পর অথবা একটি নির্দিষ্ট সংখ্যক মেসেজের পর সিঙ্ক্রোনাইজ করতে পারেন। এগুলো পরস্পর স্বতন্ত্র। উদাহরণস্বরূপ,

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

অথবা

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

<AsynchronousConfiguration>/<SyncIntervalInSeconds> এলিমেন্ট

১০ সেকেন্ডের ব্যবধান পর অ্যাসিঙ্ক্রোনাস আপডেট সম্পন্ন হওয়ার ডিফল্ট আচরণটি পরিবর্তন করতে এটি ব্যবহার করুন।

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

লিমিটস টপিকে বর্ণিত নিয়ম অনুযায়ী সিঙ্ক ইন্টারভ্যাল অবশ্যই ১০ সেকেন্ড বা তার বেশি হতে হবে।

<অ্যাসিঙ্ক্রোনাস কনফিগারেশন>/<সিঙ্ক মেসেজ সংখ্যা> উপাদান

কোটা আপডেটের মধ্যবর্তী সময়ে সমস্ত Apigee মেসেজ প্রসেসর জুড়ে অনুরোধের সংখ্যা নির্দিষ্ট করে।

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

এই উদাহরণে উল্লেখ করা হয়েছে যে, প্রতিটি Apigee Edge মেসেজ প্রসেসর জুড়ে প্রতি ৫টি অনুরোধ পর পর কোটা সংখ্যা আপডেট করা হয়।

<শনাক্তকারী> উপাদান

ফ্লো ভেরিয়েবলের উপর ভিত্তি করে অনন্য কাউন্টার তৈরি করার জন্য পলিসি কনফিগার করতে <Identifier> এলিমেন্টটি ব্যবহার করুন।

আপনি যদি এই উপাদানটি ব্যবহার না করেন, তাহলে নীতিমালাটি একটি একক কাউন্টার ব্যবহার করে যা কোটার বিপরীতে প্রয়োগ করা হয়।

এই উপাদানটি নিম্নলিখিত Apigee কমিউনিটি পোস্টেও আলোচনা করা হয়েছে: বিভিন্ন পলিসি জুড়ে কোটা শনাক্তকারী ।

<Identifier ref="verifyapikey.verify-api-key.client_id"/>

বৈশিষ্ট্য

<MessageWeight> উপাদান

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

উদাহরণস্বরূপ, আপনি POST মেসেজগুলোকে GET মেসেজের তুলনায় দ্বিগুণ "ভারী" বা ব্যয়বহুল হিসেবে গণনা করতে চান। এজন্য, আপনি একটি POST-এর জন্য MessageWeight ২ এবং একটি GET-এর জন্য ১ সেট করেন। আপনি এমনকি MessageWeight ০-ও সেট করতে পারেন, যাতে অনুরোধটি কাউন্টারকে প্রভাবিত না করে। এই উদাহরণে, যদি কোটা প্রতি মিনিটে ১০টি মেসেজ হয় এবং POST অনুরোধের জন্য MessageWeight 2 হয়, তাহলে কোটাটি যেকোনো ১০ মিনিটের ব্যবধানে ৫টি POST অনুরোধের অনুমতি দেবে। কাউন্টার রিসেট হওয়ার আগে যেকোনো অতিরিক্ত অনুরোধ, তা POST বা GET যাই হোক না কেন, প্রত্যাখ্যান করা হবে।

MessageWeight মান একটি ফ্লো ভেরিয়েবলের মাধ্যমে নির্দিষ্ট করতে হবে, এবং এটি HTTP হেডার, কোয়েরি প্যারামিটার, একটি XML বা JSON রিকোয়েস্ট পেলোড, বা অন্য যেকোনো ফ্লো ভেরিয়েবল থেকে নেওয়া যেতে পারে। উদাহরণস্বরূপ, আপনি weight নামের একটি হেডারে এটি সেট করতে পারেন:

<MessageWeight ref="message_weight"/>

প্রবাহ পরিবর্তনশীল

যখন একটি কোটা পলিসি কার্যকর হয়, তখন নিম্নলিখিত পূর্বনির্ধারিত ফ্লো ভেরিয়েবলগুলো স্বয়ংক্রিয়ভাবে পূরণ হয়ে যায়। ফ্লো ভেরিয়েবল সম্পর্কে আরও তথ্যের জন্য, ভেরিয়েবল রেফারেন্স দেখুন।

ত্রুটির রেফারেন্স

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

রানটাইম ত্রুটি

নীতি কার্যকর করার সময় এই ত্রুটিগুলি ঘটতে পারে৷

স্থাপনার ত্রুটি

ফল্ট ভেরিয়েবল

যখন এই নীতি একটি ত্রুটি ট্রিগার করে তখন এই ভেরিয়েবলগুলি সেট করা হয়৷ আরও তথ্যের জন্য, নীতি ত্রুটি সম্পর্কে আপনার যা জানা দরকার তা দেখুন।

উদাহরণ ত্রুটি প্রতিক্রিয়া

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

উদাহরণ দোষ নিয়ম

<FaultRules>
    <FaultRule name="Quota Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "QuotaViolation") </Condition>
        </Step>
        <Condition>ratelimit.Quota-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

স্কিমা

সম্পর্কিত বিষয়

কোটা নীতি পুনরায় সেট করুন

স্পাইকঅ্যারেস্ট নীতি

কোটা, স্পাইক অ্যারেস্ট এবং কনকারেন্ট রেট লিমিট পলিসিগুলির তুলনা

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

কী

একটি এপিআই প্রক্সি নির্দিষ্ট সময়কালে (যেমন মিনিট, ঘন্টা, দিন, সপ্তাহ বা মাস) কতগুলো অনুরোধ বার্তা গ্রহণ করবে, তা নির্ধারণ করতে কোটা নীতি ব্যবহার করুন। আপনি এপিআই প্রক্সি অ্যাক্সেসকারী সমস্ত অ্যাপের জন্য কোটা একই রাখতে পারেন, অথবা নিম্নলিখিত বিষয়গুলোর উপর ভিত্তি করে কোটা নির্ধারণ করতে পারেন:

• যে পণ্যটিতে এপিআই প্রক্সি রয়েছে
• এপিআই-এর জন্য অনুরোধকারী অ্যাপটি
• অ্যাপ ডেভেলপার
• আরও অনেক মানদণ্ড

সামগ্রিক ট্র্যাফিক স্পাইক থেকে সুরক্ষা পেতে কোটা ব্যবহার করবেন না। এর জন্য স্পাইক অ্যারেস্ট পলিসি ব্যবহার করুন। স্পাইক অ্যারেস্ট পলিসি দেখুন।

ভিডিও

এই ভিডিওগুলিতে কোটা নীতির মাধ্যমে কোটা ব্যবস্থাপনার সাথে পরিচয় করিয়ে দেওয়া হয়েছে:

নমুনা

এই নীতি কোডের নমুনাগুলো নিম্নোক্ত উপায়ে কোটার মেয়াদ শুরু ও শেষ করার পদ্ধতি ব্যাখ্যা করে:

<Quota name="CheckQuota">
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

<Quota name="DeveloperQuota">
  <Identifier ref="verifyapikey.verify-api-key.client_id"/>
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/>
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/>
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/>
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2017-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<AssignMessage async="false" continueOnError="false" enabled="true" name="ReturnQuotaVars">
    <AssignTo createNew="false" type="response"/>
    <Set>
        <Headers>
            <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
            <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
            <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/>
  <StartTime>2017-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Identifier ref="request.queryparam.id"/>

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

About the Quota policy

A Quota is an allotment of request messages that an API proxy can handle over a time period, such as minute, hour, day, week, or month. The policy maintains counters that tally the number of requests received by the API proxy. This capability enables API providers to enforce limits on the number of API calls made by apps over an interval of time. Using Quota policies you can, for example, limit apps to 1 request per minute, or to 10,000 requests per month.

For example, if a Quota is defined as 10,000 messages per month, rate-limiting begins after the 10,000th message. It doesn't matter whether 10,000 messages were counted on the first day or the last day of that period; no additional requests area allowed until the Quota counter automatically resets at the end of the specified time interval, or until the Quota is explicitly reset using Reset Quota policy .

A variation on Quota called SpikeArrest prevents traffic spikes (or bursts) that can be caused by a sudden increase in usage, buggy clients, or malicious attacks. For more information on SpikeArrest, see Spike Arrest policy .

Quotas apply to individual API proxies and are not distributed among API proxies. For example, if you have three API proxies in an API product, a single quota is not shared across all three even if all three use the same quota policy configuration.

Quota policy types

The Quota policy supports several different types of policies: default, calendar , flexi , and rollingwindow . Each type defines when the quota counter starts and when it resets, as shown in the following table:

For type="calendar" , you must specify the value of <StartTime> .

The table does not list the value for the rollingwindow type. Rolling window quotas work by setting the size of a quota "window", such as a one hour or one day window. When a new request comes in, the policy determines if the quota has been exceeded in the past "window" of time.

For example, you define a two hour window that allows 1000 requests. A new request comes in at 4:45 PM.The policy calculates the quota count for the past two hour window, meaning the number of requests since 2:45 PM. If the quota limit has not been exceeded in that two-hour window, then the request is allowed.

One minute later, at 4:46 PM, another request comes in. Now the policy calculates the quota count since 2:46 PM to determine if the limit has been exceeded.

For the rollingwindow type, the counter never resets, but is recalculated on each request.

Understanding quota counters

By default, a Quota policy maintains a single counter, regardless of how many times you reference it in an API proxy. The name of the quota counter is based on the name attribute of the policy.

For example, you create a Quota policy named MyQuotaPolicy with a limit of 5 requests and place it on multiple flows (Flow A, B, and C) in the API proxy. Even though it is used in multiple flows, it maintains a single counter that is updated by all instances of the policy:

• Flow A is executed -> MyQuotaPolicy is executed and its counter = 1
• Flow B is executed -> MyQuotaPolicy is executed and its counter = 2
• Flow A is executed -> MyQuotaPolicy is executed and its counter = 3
• Flow C is executed -> MyQuotaPolicy is executed and its counter = 4
• Flow A is executed -> MyQuotaPolicy is executed and its counter = 5

The next request to any of the three flows is rejected because the quota counter has reached its limit.

Using the same Quota policy in more than one place in an API proxy flow, which can unintentionally cause Quota to run out faster than you expected, is an anti-pattern described in The Book of Apigee Edge Antipatterns .

Alternatively, you can define multiple Quota policies in your API proxy and use a different policy in each flow. Each Quota policy maintains its own counter, based on the name attribute of the policy.

Or, use the <Class> or <Identifier> elements in the Quota policy to define multiple, unique counters in a single policy. By using these elements, a single policy can maintain different counters based on the app making the request, the app developer making the request, a client ID or other client identifier, and more. See the examples above for more information on using the <Class> or <Identifier> elements.

Time notation

All Quota times are set to the Coordinated Universal Time (UTC) time zone.

Quota time notation follows the international standard date notation defined in International Standard ISO 8601 .

Dates are defined as year, month, and day, in the following format: YYYY-MM-DD . For example, 2015-02-04 represents February 4, 2015.

Time of day is defined as hours, minutes, and seconds in the following format: hours:minutes:seconds . For example, 23:59:59 represents the time one second before midnight.

Note that two notations, 00:00:00 and 24:00:00 , are available to distinguish the two midnights that can be associated with one date. Therefore 2015-02-04 24:00:00 is the same date and time as 2015-02-05 00:00:00 . The latter is usually the preferred notation.

Getting quota settings from the API product configuration

You can set quota limits in API product configurations. Those limits don't automatically enforce quota. Instead, you can reference product quota settings in a quota policy. Here are some advantages of setting a quota on the product for quota policies to reference:

• Quota policies can use a uniform setting across all API proxies in the API product.
• You can make runtime changes to the quota setting on an API product, and quota policies that reference the value automatically have updated quota values.

For more information on using quota settings from an API product, see the "Dynamic Quota" example above. .

For info on configuring API products with quota limits, see Create API products .

উপাদান রেফারেন্স

Following are elements and attributes you can configure on this policy. Note that some element combinations are mutually exclusive or not required. See the samples for specific usage. The verifyapikey.VerifyAPIKey.apiproduct.* variables below are available by default when a Verify API Key policy called "VerifyAPIKey" is used to check the app's API key in the request. The variable values come from the quota settings on the API product that the key is associated with, as described in Getting quota settings from the API product configuration .

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="5000"/>
        <Allow class="off_peak_time" count="1000"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>
   <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2017-7-16 12:00:00</StartTime>
   <Distributed>false</Distributed>
   <Synchronous>false</Synchronous>
   <AsynchronousConfiguration>
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
      <SyncMessageCount>5</SyncMessageCount>
   </AsynchronousConfiguration>
   <Identifier/>
   <MessageWeight/>
</Quota>

<Quota> attributes

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">

নিম্নলিখিত বৈশিষ্ট্যগুলো এই পলিসির জন্য নির্দিষ্ট।

নিম্নলিখিত সারণী সমস্ত নীতির মূল উপাদানগুলির জন্য সাধারণ বৈশিষ্ট্যগুলি বর্ণনা করে:

<DisplayName> উপাদান

ম্যানেজমেন্ট UI প্রক্সি এডিটরে নীতিটিকে একটি ভিন্ন, প্রাকৃতিক-ভাষা নামের সাথে লেবেল করতে name বৈশিষ্ট্য ছাড়াও ব্যবহার করুন।

<DisplayName>Policy Display Name</DisplayName>

<Allow> element

Specifies the count limit for the quota. If the counter for the policy reaches this limit value, subsequent calls are rejected until the counter resets.

Shown below are three ways to set the <Allow> element:

<Allow count="2000"/>

<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>

If you specify both count and countRef , then countRef gets the priority. If countRef does not resolve at runtime, then the value of count is used.

বৈশিষ্ট্য

<Allow>/<Class> element

The <Class> element lets you conditionalize the value of the <Allow> element based on the value of a flow variable. For each different <Allow> child tag of <Class> , the policy maintains a different counter.

To use the <Class> element, specify a flow variable using the ref attribute to the <Class> tag. Edge then uses the value of the flow variable to select one of the <Allow> child tags to determine the allowed count of the policy. Edge matches the value of the flow variable to the class attribute of the <Allow> tag, as shown below:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

In this example, the current quota counter is determined by the value of the time_variable query param passed with each request. That variable can have a value of peak_time or off_peak_time . If the query param contains an invalid value, the policy returns a quota violation error.

বৈশিষ্ট্য

<Allow>/<Class>/<Allow> element

The <Allow> element specifies the limit for a quota counter defined by the <Class> element. For each different <Allow> child tag of <Class> , the policy maintains a different counter.

উদাহরণস্বরূপ:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

In this example, the Quota policy maintains two quota counters named of peak_time and off_peak_time .

বৈশিষ্ট্য

<Interval> element

Use to specify an integer (for example, 1, 2, 5, 60, and so on) that will be paired with the TimeUnit you specify (minute, hour, day, week, or month) to determine a time period during which Edge calculates quota use.

For example, an Interval of 24 with a TimeUnit of hour means that the quota will be calculated over the course of 24 hours.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>

বৈশিষ্ট্য

<TimeUnit> element

Use to specify the unit of time applicable to the quota.

For example, an Interval of 24 with a TimeUnit of hour means that the quota will be calculated over the course of 24 hours.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>

বৈশিষ্ট্য

<StartTime> element

When type is set to calendar, specifies the date and time when the quota counter will begin counting, regardless of whether any requests have been received from any apps.

উদাহরণস্বরূপ:

<StartTime>2017-7-16 12:00:00</StartTime>

<Distributed> element

An installation of Edge can use one or more Message Processors to process requests. Set this element to true to specify that the policy should maintain a central counter and continuously synchronize it across all Message Processors. The message processors can be across availability zones and/or regions.

If you use the default value of false , then you might exceed your quota because the count for each Message Processor is not shared:

<Distributed>true</Distributed>

To guarantee that the counters are synchronized, and updated on every request, set <Distributed> and <Synchronous> to true:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>

<Synchronous> element

Set to true to update a distributed quota counter synchronously. This means that the update to the counter are made at the same time the quota is checked on a request to the API. Set to true if it is essential that you not allow any API calls over the quota.

Set to false to update the quota counter asynchronously. This means that it is possible that some API calls exceeding the quota will go through, depending on when the quota counter in the central repository is asynchronously updated. However, you will not face the potential performance impacts associated with synchronous updates.

The default asynchronous update interval is 10 seconds. Use the AsynchronousConfiguration element to configure this asynchronous behavior.

<Synchronous>false</Synchronous>

<AsynchronousConfiguration> element

Configures the synchronization interval amongst distributed quota counters when the policy configuration element <Synchronous> is either not present or present and set to false .

You can synchronize either after a time period or a message count, using either the SyncIntervalInSeconds or SyncMessageCount child elements. They are mutually exclusive. For example,

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

অথবা

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

<AsynchronousConfiguration>/<SyncIntervalInSeconds> element

Use this to override the default behavior in which asynchronous updates are performed after an interval of 10 seconds.

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

The sync interval must be >= 10 seconds as described in the Limits topic.

<AsynchronousConfiguration>/<SyncMessageCount> element

Specifies the number of requests across all Apigee message processors between quota updates.

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

This example specifies that the quota count is updated every 5 requests across each Apigee Edge message processor.

<Identifier> element

Use the <Identifier> element to configure the policy to create unique counters based on a flow variable.

If you don't use this element, the policy uses a single counter that is applied against the quota.

This element is also discussed in the following Apigee Community post: Quota identifier across different policies .

<Identifier ref="verifyapikey.verify-api-key.client_id"/>

বৈশিষ্ট্য

<MessageWeight> element

Use to specify the weight assigned to each message. Use message weight to increase impact of request messages that, for example, consume more computational resources than others.

For example, you want to count POST messages as being twice as "heavy" or expensive, as GET messages. Therefore, you set the MessageWeight to 2 for a POST and 1 for a GET. You can even set the MessageWeight to 0 so the request does not affect the counter. In this example, if the quota is 10 messages per minute and the MessageWeight for POST requests is 2 , then the quota will permits 5 POST requests in any 10 minute interval. Any additional request, POST or GET, before the counter resets are rejected.

A value representing MessageWeight must be specified by a flow variable, and can be extracted from HTTP headers, query parameters, an XML or JSON request payload, or any other flow variable. For example, you set it in a header named weight :

<MessageWeight ref="message_weight"/>

প্রবাহ পরিবর্তনশীল

The following predefined Flow variables are automatically populated when a Quota policy executes. For more information about Flow variables, see Variables reference .

ত্রুটির রেফারেন্স

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

রানটাইম ত্রুটি

নীতি কার্যকর করার সময় এই ত্রুটিগুলি ঘটতে পারে৷

স্থাপনার ত্রুটি

ফল্ট ভেরিয়েবল

যখন এই নীতি একটি ত্রুটি ট্রিগার করে তখন এই ভেরিয়েবলগুলি সেট করা হয়৷ আরও তথ্যের জন্য, নীতি ত্রুটি সম্পর্কে আপনার যা জানা দরকার তা দেখুন।

উদাহরণ ত্রুটি প্রতিক্রিয়া

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

উদাহরণ দোষ নিয়ম

<FaultRules>
    <FaultRule name="Quota Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "QuotaViolation") </Condition>
        </Step>
        <Condition>ratelimit.Quota-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

স্কিমা

সম্পর্কিত বিষয়

ResetQuota policy

স্পাইকঅ্যারেস্ট নীতি

Comparing Quota, Spike Arrest, and Concurrent Rate Limit Policies