আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য
<Rate> এলিমেন্টের মাধ্যমে স্পাইক অ্যারেস্ট নীতি ট্রাফিকের আকস্মিক বৃদ্ধি থেকে রক্ষা করে। এই
এলিমেন্ট, API প্রক্সি দ্বারা প্রসেস করা এবং ব্যাকএন্ডে পাঠানো অনুরোধের সংখ্যাকে থ্রটল করে,
এর ফলে পারফর্ম্যান্স ল্যাগ ও ডাউনটাইম থেকে রক্ষা পাওয়া যায়।
<SpikeArrest> এলিমেন্ট
স্পাইক অ্যারেস্ট নীতি নির্ধারণ করে।
| ডিফল্ট ভ্যালু | নিচে ডিফল্ট নীতি ট্যাব দেখুন |
| প্রয়োজনীয়? | ঐচ্ছিক |
| টাইপ করুন | জটিল অবজেক্ট |
| পেরেন্ট এলিমেন্ট | প্রযোজ্য নয় |
| চাইল্ড এলিমেন্ট |
<Identifier><MessageWeight><Rate> (প্রয়োজনীয়)<UseEffectiveCount> |
সিন্ট্যাক্স
<SpikeArrest> এলিমেন্ট নিম্নলিখিত সিনট্যাক্স ব্যবহার করে:
<SpikeArrest continueOnError="[false|true]" enabled="[true|false]" name="policy_name" > <DisplayName>display_name</DisplayName> <Properties/> <Identifier ref="flow_variable"/> <MessageWeight ref="flow_variable"/> <Rate ref="flow_variable">rate[pm|ps]</Rate> <UseEffectiveCount>[false|true]</UseEffectiveCount> </SpikeArrest>
ডিফল্ট নীতি
Edge UI-তে আপনার ফ্লোতে স্পাইক অ্যারেস্ট নীতি যোগ করলে, নিম্নলিখিত উদাহরণে ডিফল্ট সেটিংস দেখানো হয়:
<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1"> <DisplayName>Spike Arrest-1</DisplayName> <Properties/> <Identifier ref="request.header.some-header-name"/> <MessageWeight ref="request.header.weight"/> <Rate>30ps</Rate> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>
এই উপাদানটির নিম্নলিখিত বৈশিষ্ট্যগুলি রয়েছে যা সমস্ত নীতিতে সাধারণ:
| বৈশিষ্ট্য | ডিফল্ট | প্রয়োজন? | বর্ণনা |
|---|---|---|---|
name | N/A | প্রয়োজন | নীতির অভ্যন্তরীণ নাম। ঐচ্ছিকভাবে, ম্যানেজমেন্ট UI প্রক্সি এডিটরে নীতিটিকে একটি ভিন্ন, প্রাকৃতিক-ভাষা নামের সাথে লেবেল করতে |
continueOnError | মিথ্যা | ঐচ্ছিক | একটি নীতি ব্যর্থ হলে একটি ত্রুটি ফেরত দিতে "false" এ সেট করুন৷ এটি বেশিরভাগ নীতির জন্য প্রত্যাশিত আচরণ। একটি নীতি ব্যর্থ হওয়ার পরেও প্রবাহ সম্পাদন অব্যাহত রাখতে "সত্য" তে সেট করুন৷ |
enabled | সত্য | ঐচ্ছিক | নীতি প্রয়োগ করতে "সত্য" এ সেট করুন। নীতিটি "বন্ধ" করতে "মিথ্যা" এ সেট করুন। নীতিটি প্রবাহের সাথে সংযুক্ত থাকলেও তা কার্যকর করা হবে না। |
async | মিথ্যা | অবচয় | এই বৈশিষ্ট্যটি অবমূল্যায়ন করা হয়েছে৷ |
উদাহরণ
আপনি কীভাবে স্পাইক অ্যারেস্ট নীতি ব্যবহার করতে পারেন তা নিম্নলিখিত উদাহরণ থেকে জানতে পারবেন:
নমুনা ১
নিচের উদাহরণটি রেটকে প্রতি সেকেন্ডে পাঁচটি হিসেবে সেট করে:
<SpikeArrest name="Spike-Arrest-1"> <Rate>5ps</Rate> </SpikeArrest>
নীতিটি রেটকে মসৃণ করে, প্রতি ২০০ মিলি সেকেন্ডে একটি অনুরোধকে অনুমতি দেওয়া হয় (১০০০/৫)।
নমুনা ২
নিচে দেওয়া উদাহরণে রেট প্রতি মিনিটে ৩০০ হিসেবে সেট করা হয়েছে:
<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast"> <DisplayName>SpikeArreast</DisplayName> <Rate>300pm</Rate> </SpikeArrest>
কার্যকর রেট হল ৩০০pm, অর্থাৎ প্রতি ২০০ মিলিসেকেন্ডে একটি নতুন টোকেন বালতিতে যোগ করা হয়। messagesPerPeriod-এর ১০% হিসেবে বালতির সাইজ সবসময় কনফিগার করা হয়। তাই, messagesPerPeriod-এর মান ৩০০ হলে, বাকেট সাইজ ৩০টি টোকেন হয়।
উদাহরণ ৩
নিম্নলিখিত উদাহরণে প্রতি মিনিটে ১২টি অনুরোধের সীমা নির্ধারণ করা হয়েছে (প্রতি পাঁচ সেকেন্ডে একটি অনুরোধ অনুমোদিত, অথবা ৬০/১২):
<SpikeArrest name="Spike-Arrest-1"> <Rate>12pm</Rate> <Identifier ref="client_id" /> <MessageWeight ref="request.header.weight" /> </SpikeArrest>
এছাড়াও, <MessageWeight> এলিমেন্ট একটি কাস্টম ভ্যালু (the
weight হেডার) গ্রহণ করে যা নির্দিষ্ট অ্যাপ বা ক্লায়েন্টের জন্য মেসেজ ওয়েট অ্যাডজাস্ট করে। এটি
<Identifier> এলিমেন্ট দিয়ে শনাক্ত করা এন্টিটির থ্রটলিংয়ের উপর
অতিরিক্ত নিয়ন্ত্রণ প্রদান করে।
উদাহরণ ৪
নিচে দেওয়া উদাহরণে Spike Arrest-কে
অনুরোধের মাধ্যমে সেট করা রানটাইম ভ্যালু খুঁজতে বলা হয়েছে, যা request.header.runtime_rate ফ্লো ভেরিয়েবল হিসেবে পাস করা হয়েছে:
<SpikeArrest name="Spike-Arrest-1"> <Rate ref="request.header.runtime_rate" /> </SpikeArrest>
ফ্লো ভেরিয়েবলের ভ্যালু অবশ্যই intpm বা
intps ফর্ম্যাটে হতে হবে।
এই উদাহরণটি ব্যবহার করে দেখতে, নিম্নলিখিত ধরনের একটি অনুরোধ এক্সিকিউট করুন:
curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'
চাইল্ড এলিমেন্ট রেফারেন্স
এই বিভাগে <SpikeArrest>-এর চাইল্ড এলিমেন্ট সম্পর্কে বর্ণনা করা হয়েছে।
<DisplayName>
ম্যানেজমেন্ট UI প্রক্সি এডিটরে অন্য, আরও স্বাভাবিক-শোনা নাম দিয়ে নীতি লেবেল করতে
name অ্যাট্রিবিউট ছাড়াও ব্যবহার করুন।
<DisplayName> এলিমেন্ট সব নীতির ক্ষেত্রে প্রযোজ্য।
| ডিফল্ট ভ্যালু | প্রযোজ্য নয় |
| আবশ্যক? | ঐচ্ছিক। আপনি <DisplayName> বাদ দিলে, নীতির name অ্যাট্রিবিউটের ভ্যালু ব্যবহার করা হয় |
| Type | স্ট্রিং |
| পেরেন্ট এলিমেন্ট | <PolicyElement> |
| চাইল্ড এলিমেন্ট | কোনওটিই নয় |
<DisplayName> এলিমেন্ট নিম্নলিখিত সিনট্যাক্স ব্যবহার করে:
সিন্ট্যাক্স
<PolicyElement> <DisplayName>policy_display_name</DisplayName> ... </PolicyElement>
উদাহরণ
<PolicyElement> <DisplayName>My Validation Policy</DisplayName> </PolicyElement>
<DisplayName> এলিমেন্টে কোনও অ্যাট্রিবিউট বা চাইল্ড এলিমেন্ট নেই।
<Identifier>
অনুরোধগুলিকে কীভাবে গ্রুপ করা হবে তা বেছে নিতে দেয় যাতে ক্লায়েন্টের উপর ভিত্তি করে স্পাইক অ্যারেস্ট নীতি প্রয়োগ করা যায়। যেমন, আপনি ডেভেলপার আইডি অনুযায়ী অনুরোধ গ্রুপ করতে পারেন, সেক্ষেত্রে প্রতিটি ডেভেলপারের অনুরোধ তাদের নিজস্ব স্পাইক অ্যারেস্ট রেটের মধ্যে গণনা করা হবে এবং প্রক্সিতে আসা সব অনুরোধ গণনা করা হবে না।
অনুরোধ থ্রটলিংয়ের উপর আরও সূক্ষ্ম-গ্রেনুলার
কন্ট্রোল পেতে <MessageWeight> এলিমেন্টের সাথে একসাথে ব্যবহার করুন।
আপনি <Identifier> এলিমেন্ট ফাঁকা রাখলে, সেই API প্রক্সিতে আসা সব অনুরোধের জন্য একটি রেট
সীমা প্রয়োগ করা হয়।
| ডিফল্ট ভ্যালু | প্রযোজ্য নয় |
| প্রয়োজনীয়? | ঐচ্ছিক |
| টাইপ করুন | স্ট্রিং |
| পেরেন্ট এলিমেন্ট |
<SpikeArrest>
|
| চাইল্ড এলিমেন্ট | কোনওটিই নয় |
সিন্ট্যাক্স
<SpikeArrest continueOnError="[false|true]" enabled="[true|false]" name="policy_name" > <Identifier ref="flow_variable"/> </SpikeArrest>
নমুনা ১
নিচের উদাহরণটি ডেভেলপার আইডি পিছু স্পাইক অ্যারেস্ট নীতি প্রয়োগ করে:
<SpikeArrest name="Spike-Arrest-1"> <Identifier ref="developer.id"/> <Rate>42pm</Rate/> </SpikeArrest>
নিচের সারণীতে <Identifier>-এর অ্যাট্রিবিউট বর্ণনা করা হয়েছে:
| অ্যাট্রিবিউট | বিবরণ | ডিফল্ট | উপস্থিতি |
|---|---|---|---|
ref |
যেসব ভেরিয়েবলের মাধ্যমে স্পাইক অ্যারেস্ট ইনকামিং অনুরোধ গ্রুপ করে সেগুলিকে শনাক্ত করে। কোনও অনন্য ক্লায়েন্টকে বোঝাতে আপনি যেকোনও ফ্লো ভেরিয়েবল ব্যবহার করতে পারেন, যেমন VerifyAPIKey নীতির সাথে উপলভ্য ভেরিয়েবল। এছাড়াও, আপনি JavaScript নীতি বা AssignMessage নীতি ব্যবহার করে কাস্টম ভেরিয়েবল সেট করতে পারবেন। | প্রযোজ্য নয় | প্রয়োজনীয় |
এই এলিমেন্টটি নিম্নলিখিত Apigee কমিউনিটি পোস্টেও আলোচনা করা হয়েছে: বিভিন্ন নীতি জুড়ে কোটা শনাক্তকারী।
<MessageWeight>
প্রতিটি মেসেজের জন্য নির্দিষ্ট করা ওয়েটিং উল্লেখ করে। মেসেজ ওয়েট স্পাইক অ্যারেস্ট রেট গণনার ক্ষেত্রে একটি অনুরোধের প্রভাবকে পরিবর্তন করে। মেসেজ ওয়েট যেকোনও ফ্লো ভেরিয়েবল হতে পারে, যেমন HTTP হেডার, কোয়েরি প্যারামিটার, ফর্ম প্যারামিটার বা মেসেজ বডির কন্টেন্ট। এছাড়াও, আপনি JavaScript নীতি অথবা AssignMessage নীতি ব্যবহার করে কাস্টম ভেরিয়েবল ব্যবহার করতে পারবেন।
নির্দিষ্ট ক্লায়েন্ট বা অ্যাপের
মাধ্যমে অনুরোধ আরও বেশি থ্রটল করতে, <Identifier>-এর সাথে একসাথে ব্যবহার করুন।
যেমন, স্পাইক অ্যারেস্ট <Rate> যদি 10pm হয় এবং কোনও অ্যাপ যদি 2 ওয়েট সহ
অনুরোধ জমা দেয়, তাহলে সেই ক্লায়েন্ট থেকে প্রতি মিনিটে শুধুমাত্র পাঁচটি মেসেজ পাঠানোর অনুমতি
দেওয়া হবে, কারণ প্রতিটি অনুরোধকে ২ হিসেবে গণনা করা হয়।
| ডিফল্ট ভ্যালু | প্রযোজ্য নয় |
| প্রয়োজনীয়? | ঐচ্ছিক |
| টাইপ করুন | পূর্ণসংখ্যা |
| পেরেন্ট এলিমেন্ট |
<SpikeArrest>
|
| চাইল্ড এলিমেন্ট | কোনওটিই নয় |
সিন্ট্যাক্স
<SpikeArrest continueOnError="[false|true]" enabled="[true|false]" name="policy_name" > <MessageWeight ref="flow_variable"/> </SpikeArrest>
নমুনা ১
নিম্নলিখিত উদাহরণে প্রতি মিনিটে ১২টি অনুরোধের সীমা নির্ধারণ করা হয়েছে (প্রতি পাঁচ সেকেন্ডে একটি অনুরোধ অনুমোদিত, অথবা ৬০/১২):
<SpikeArrest name="Spike-Arrest-1"> <Rate>12pm</Rate> <Identifier ref="client_id" /> <MessageWeight ref="request.header.weight" /> </SpikeArrest>
এই উদাহরণে, <MessageWeight> একটি কাস্টম ভ্যালু (অনুরোধে weight
হেডার) গ্রহণ করে যা নির্দিষ্ট ক্লায়েন্টের জন্য মেসেজ ওয়েট অ্যাডজাস্ট করে। এটি
<Identifier> এলিমেন্ট দিয়ে শনাক্ত করা এন্টিটির থ্রটলিংয়ের উপর
অতিরিক্ত নিয়ন্ত্রণ প্রদান করে।
নিচের সারণীতে <MessageWeight>-এর অ্যাট্রিবিউট বর্ণনা করা হয়েছে:
| অ্যাট্রিবিউট | বিবরণ | উপস্থিতি | ডিফল্ট |
|---|---|---|---|
ref |
নির্দিষ্ট ক্লায়েন্টের জন্য মেসেজের ওজন ধারণকারী ফ্লো ভেরিয়েবলকে শনাক্ত করে। এটি যেকোনও ফ্লো ভেরিয়েবল হতে পারে, যেমন HTTP কোয়েরি প্যারামিটার, হেডার বা মেসেজ বডির কন্টেন্ট। আরও তথ্যের জন্য, ফ্লো ভেরিয়েবল রেফারেন্স দেখুন। এছাড়াও, আপনি JavaScript নীতি বা AssignMessage নীতি ব্যবহার করে কাস্টম ভেরিয়েবল সেট করতে পারেন। | প্রয়োজনীয় | প্রযোজ্য নয় |
<Rate>
প্রতি মিনিট বা প্রতি সেকেন্ডের ব্যবধানে অনুমোদিত অনুরোধের সংখ্যা সেট করে ট্রাফিক স্পাইক (বা বার্স্ট) সীমিত করার হার নির্দিষ্ট করে।
এছাড়াও, আপনি এই এলিমেন্টটি <Identifier> এবং <MessageWeight>-এর সাথে
একযোগে ব্যবহার করতে পারেন যাতে ক্লায়েন্টের থেকে পাওয়া ভ্যালু গ্রহণ করে রানটাইমে ট্রাফিক
স্মুথলি থ্রটল করা যায়।
| ডিফল্ট ভ্যালু | প্রযোজ্য নয় |
| প্রয়োজনীয়? | প্রয়োজনীয় |
| টাইপ করুন | পূর্ণসংখ্যা |
| পেরেন্ট এলিমেন্ট |
<SpikeArrest>
|
| চাইল্ড এলিমেন্ট | কোনওটিই নয় |
সিন্ট্যাক্স
আপনি নিম্নলিখিত পদ্ধতিগুলির মধ্যে একটিতে রেট নির্দিষ্ট করতে পারেন:
<Rate>এলিমেন্টের বডি হিসেবে আপনি নির্দিষ্ট করেন এমন একটি স্ট্যাটিক রেট- একটি পরিবর্তনযোগ্য ভ্যালু, যা ক্লায়েন্ট পাস করতে পারে;
refঅ্যাট্রিবিউট ব্যবহার করে ফ্লো ভেরিয়েবলের নাম শনাক্ত করুন
<SpikeArrest continueOnError="[false|true]" enabled="[true|false]" name="policy_name" > <Rate ref="flow_variable">rate[pm|ps]</Rate> </SpikeArrest>
সঠিক রেট ভ্যালু (ভেরিয়েবল ভ্যালু হিসেবে বা এলিমেন্টের বডিতে সংজ্ঞায়িত) অবশ্যই নিম্নলিখিত ফর্ম্যাট মেনে চলতে হবে:
intps(প্রতি সেকেন্ডে অনুরোধের সংখ্যা, মিলিসেকেন্ডের ইন্টারভ্যালে স্মুথ করা হয়েছে)intpm(প্রতি মিনিটে অনুরোধের সংখ্যা, সেকেন্ডের ব্যবধানে স্মুথ করা হয়েছে)
int-এর মান অবশ্যই ধনাত্মক, অশূন্য পূর্ণসংখ্যা হতে হবে।
নমুনা ১
নিচের উদাহরণে রেটকে প্রতি সেকেন্ডে পাঁচটি অনুরোধে সেট করা হয়েছে:
<SpikeArrest name="Spike-Arrest-1"> <Rate>5ps</Rate> </SpikeArrest>
নীতিটি রেটকে মসৃণ করে এবং প্রতি ২০০ মিলি সেকেন্ডে একটি অনুরোধকে অনুমতি দেয় (১০০০/৫)।
নমুনা ২
নিচে দেওয়া উদাহরণে রেট প্রতি মিনিটে ১২টি অনুরোধ হিসেবে সেট করা হয়েছে:
<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast"> <DisplayName>SpikeArreast</DisplayName> <Rate>300pm</Rate> </SpikeArrest>
এই উদাহরণ নীতিটি রেটকে মসৃণ করে এবং প্রতি পাঁচ সেকেন্ডে একটি অনুরোধকে অনুমতি দেয় (৬০/১২)।
নিচের সারণীতে <Rate>-এর অ্যাট্রিবিউট বর্ণনা করা হয়েছে:
| অ্যাট্রিবিউট | বিবরণ | উপস্থিতি | ডিফল্ট |
|---|---|---|---|
ref |
ফ্লো ভেরিয়েবল শনাক্ত করে যা রেট নির্দিষ্ট করে। এটি যেকোনও ফ্লো
ভেরিয়েবল হতে পারে, যেমন HTTP কোয়েরি প্যারামিটার, হেডার বা মেসেজ বডির কন্টেন্ট অথবা KVM-এর মতো কোনও ভ্যালু।
আরও তথ্যের জন্য, ফ্লো ভেরিয়েবল রেফারেন্স দেখুন।
এছাড়াও, আপনি JavaScript নীতি বা AssignMessage নীতি ব্যবহার করে কাস্টম ভেরিয়েবল ব্যবহার করতে পারবেন। আপনি যদি যেমন: <Rate ref="request.header.custom_rate">1pm</Rate> এই উদাহরণে, ক্লায়েন্ট "custom_rate" হেডার পাস না করলে, API প্রক্সির জন্য রেট হল সব ক্লায়েন্টের জন্য প্রতি মিনিটে ১টি অনুরোধ। ক্লায়েন্ট "custom_rate" হেডার পাস করলে, প্রক্সি সার্ভারে থাকা সব ক্লায়েন্টের জন্য রেট সীমা ১ সেকেন্ডে ১০টি অনুরোধ হয়ে যায় — যতক্ষণ না "custom_rate" হেডার ছাড়া কোনও অনুরোধ পাঠানো হয়। বিভিন্ন ধরনের ক্লায়েন্টের জন্য কাস্টম রেট প্রয়োগ করতে, আপনি অনুরোধ গ্রুপ করার জন্য আপনি যদি |
ঐচ্ছিক | প্রযোজ্য নয় |
Rate ট্রাফিক থ্রটলিং আচরণ নির্ধারণকারী অ্যাট্রিবিউট সম্পর্কে বর্ণনা করা হয়েছে:
| অ্যাট্রিবিউট | বিবরণ |
|---|---|
messagesPerPeriod |
একটি নির্দিষ্ট সময়ের মধ্যে অনুমোদিত মেসেজের সংখ্যা নির্দিষ্ট করে। যেমন, কোনও নীতির জন্য '10ps' (প্রতি সেকেন্ডে ১০টি) কনফিগার করা হলে,
messagesPerPeriod ভ্যালু ১০ হবে। |
periodInMicroseconds |
মাইক্রোসেকেন্ডে সময়সীমা নির্ধারণ করে, যার উপর ভিত্তি করে
messagesPerPeriod গণনা করা হয়। '10ps' কনফিগারেশনের জন্য, এই ভ্যালু ১,০০০,০০০ হবে, যা এক সেকেন্ডের সমান। |
maxBurstMessageCount |
নতুন ইন্টারভ্যালের শুরুতে ইনস্ট্যান্ট বা অল্প সময়ের মধ্যে অনুমোদিত হতে পারে এমন সর্বাধিক সংখ্যক অনুরোধের প্রতিনিধিত্ব করে। |
<UseEffectiveCount>
অটো-স্কেলিং গ্রুপ ব্যবহার করার সময় মেসেজ প্রসেসর (MP) জুড়ে আপনার স্পাইক অ্যারেস্টের সংখ্যা ডিস্ট্রিবিউট করে।
সিন্ট্যাক্স
<SpikeArrest continueOnError="[false|true]" enabled="[true|false]" name="policy_name" > <UseEffectiveCount>[false|true]</UseEffectiveCount> </SpikeArrest>
নমুনা ১
নিচে দেওয়া উদাহরণে <UseEffectiveCount>-এর মান true হিসেবে সেট করা হয়েছে:
<SpikeArrest name='Spike-Arrest-1'> <Rate>40ps</Rate> <UseEffectiveCount>true</UseEffectiveCount> </SpikeArrest>
<UseEffectiveCount> এলিমেন্টটি ঐচ্ছিক। আপনার স্পাইক অ্যারেস্ট নীতি থেকে এলিমেন্ট বাদ দিলে ডিফল্ট ভ্যালু হল false
।
| ডিফল্ট ভ্যালু | মিথ্যা |
| প্রয়োজনীয়? | ঐচ্ছিক |
| টাইপ করুন | বুলিয়ান |
| পেরেন্ট এলিমেন্ট |
<SpikeArrest>
|
| চাইল্ড এলিমেন্ট | কোনওটিই নয় |
নিচের সারণীতে <UseEffectiveCount> এলিমেন্টের অ্যাট্রিবিউট সম্পর্কে বর্ণনা করা হয়েছে:
| অ্যাট্রিবিউট | বিবরণ | ডিফল্ট | উপস্থিতি |
|---|---|---|---|
ref |
<UseEffectiveCount>-এর ভ্যালু আছে এমন ভেরিয়েবল শনাক্ত করে। এটি
যেকোনও ফ্লো ভেরিয়েবল হতে পারে, যেমন HTTP কোয়েরি প্যারামিটার, হেডার বা মেসেজ বডির কন্টেন্ট। আরও
তথ্যের জন্য, ফ্লো ভেরিয়েবল রেফারেন্স দেখুন। এছাড়াও, আপনি JavaScript নীতি বা AssignMessage নীতি ব্যবহার করে কাস্টম ভেরিয়েবল
সেট করতে পারেন। |
প্রযোজ্য নয় | ঐচ্ছিক |
<UseEffectiveCount>-এর প্রভাব এর ভ্যালুর উপর নির্ভর করে:
true: কোনও MP-র স্পাইক রেট সীমা হল<Rate>-কে একই পডে থাকা বর্তমান MP-র সংখ্যা দিয়ে ভাগ করা।<Rate>-এর ভ্যালু হল এগ্রিগেট সীমা। ডায়নামিক পদ্ধতিতে MP যোগ (বা সরানো) করা হলে, তাদের ব্যক্তিগত স্পাইক রেট সীমা বাড়বে (বা কমবে), কিন্তু সামগ্রিক সীমা একই থাকবে।false: প্রতিটি MP-র স্পাইক রেট সীমা হল সেটির<Rate>-এর ভ্যালু। সব MP-র রেটের যোগফল হল এগ্রিগেট সীমা। MP যোগ (বা সরানো) হলে, তাদের ব্যক্তিগত স্পাইক রেট সীমা একই থাকবে, কিন্তু সামগ্রিক সীমা বেড়ে (বা কমে) যাবে।
SpikeArrest নীতি "টোকেন বাকেট" অ্যালগরিদম ব্যবহার করে যা আপনার নির্দিষ্ট করা রেট লিমিটকে ছোট ছোট ইন্টারভ্যালে ভাগ করে ট্রাফিকের স্পাইক মসৃণ করে। এই পদ্ধতির একটি অসুবিধা হল, অল্প সময়ের মধ্যে একাধিক বৈধ অনুরোধ এলে সেগুলি প্রত্যাখ্যান করা হতে পারে।
যেমন, আপনি যদি ৩০pm (প্রতি মিনিটে ৩০টি অনুরোধ) রেট দেন। পরীক্ষা করার সময়, আপনি হয়ত ভাবতে পারেন যে ১ সেকেন্ডে ৩০টি অনুরোধ পাঠানো যেতে পারে, যদি সেগুলি ১ মিনিটের মধ্যে আসে। তবে নীতিটি এইভাবে সেটিং প্রয়োগ করে না। আপনি যদি এটি নিয়ে ভাবেন, তাহলে ১ সেকেন্ডের মধ্যে ৩০টি অনুরোধ কিছু এনভায়রনমেন্টে একটি মিনি স্পাইক হিসেবে বিবেচনা করা যেতে পারে।
- প্রতি মিনিট রেটকে সেকেন্ড ব্যবধানে অনুমোদিত সম্পূর্ণ অনুরোধে
স্মুথ করা হয়।
যেমন, ৩০pm-কে এইভাবে স্মুথ করা হয়:
৬০ সেকেন্ড (১ মিনিট) / ৩০pm = ২-সেকেন্ডের ব্যবধান অথবা প্রতি ২ সেকেন্ডে ১টি অনুরোধ অনুমোদিত। A ২ সেকেন্ডের মধ্যে দ্বিতীয় অনুরোধ করলে তা সম্পূর্ণ হবে না। এছাড়াও, এক মিনিটের মধ্যে ৩১তম অনুরোধ করলে সেটি কাজ করবে না। - প্রতি সেকেন্ড রেটকে মিলিসেকেন্ড
ইন্টারভ্যালে অনুমোদিত সম্পূর্ণ অনুরোধে স্মুথ করা হয়।
যেমন, 10ps-কে এইভাবে মসৃণ করা হয়:
১০০০ মিলিসেকেন্ড (১ সেকেন্ড) / 10ps = ১০০ মিলিসেকেন্ডের ব্যবধান অথবা প্রতি ১০০ মিলিসেকেন্ডে ১টি অনুরোধ করার অনুমতি দেওয়া হয়। ১০০ মিলিসেকেন্ডের মধ্যে দ্বিতীয় অনুরোধ করলে তা সম্পূর্ণ হবে না। এছাড়াও, এক সেকেন্ডের মধ্যে ১১তম অনুরোধ করা হলে সেটি সম্পূর্ণ হবে না।
নিম্নলিখিত সারণীতে প্রতিটি MP-র
কার্যকর রেট লিমিটের উপর <UseEffectiveCount>-এর প্রভাব দেখানো হয়েছে:
<UseEffectiveCount>-এর ভ্যালু |
||||||
|---|---|---|---|---|---|---|
false |
false |
false |
true |
true |
true |
|
| # of MPs | 8 | 4 | 2 | 8 | 4 | 2 |
<Rate>-এর ভ্যালু |
10 | 10 | 10 | 40 | 40 | 40 |
| প্রতি MP-তে কার্যকর রেট | 10 | 10 | 10 | 5 | 10 | 20 |
| মোট সীমা | ৮০ | 40 | 20 | 40* | 40* | 40* |
* <Rate>-এর মতো। |
||||||
এই উদাহরণে, লক্ষ্য করুন যে MP-এর সংখ্যা ৪ থেকে ২-এ কমে গেলে এবং
<UseEffectiveCount> হল false, MP পিছু কার্যকরী রেট একই থাকে (১০-এ
থাকে)। কিন্তু <UseEffectiveCount> true হলে, MP-এর সংখ্যা ৪ থেকে ২-এ কমে গেলে, প্রতি MP-এর কার্যকর রেট ১০ থেকে ২০ হয়ে যায়।
ফ্লো ভেরিয়েবল
স্পাইক অ্যারেস্ট নীতি কার্যকর হলে, নিম্নলিখিত ফ্লো ভেরিয়েবল পপুলেট করা হয়:
| ভেরিয়েবেল | ধরন | অনুমতি | বিবরণ |
|---|---|---|---|
ratelimit.policy_name.failed |
বুলিয়ান | রিড-অনলি | নীতি কাজ করেনি (true বা
false) কিনা তা নির্দেশ করে। |
আরও তথ্যের জন্য, ফ্লো ভেরিয়েবল রেফারেন্স দেখুন।
সমস্যার রেফারেন্স
এই নীতি কোনও সমস্যার ট্রিগার করলে, Edge-এর দ্বারা সেট করা ফল্ট কোড, সমস্যার মেসেজ এবং ফল্ট ভেরিয়েবল এই বিভাগে বর্ণনা করা হয়েছে। সমস্যা সমাধানের জন্য আপনি যদি ফল্ট রুল ডেভেলপ করেন, তাহলে এই তথ্য জানা আপনার জন্য গুরুত্বপূর্ণ। আরও জানতে, নীতি সংক্রান্ত সমস্যা সম্পর্কে আপনার যা জানা প্রয়োজন এবং সমস্যার সমাধান করা দেখুন।
রানটাইম সমস্যা
নীতি এক্সিকিউট করার সময় এই সমস্যা হতে পারে।
| সমস্যার কোড | HTTP স্ট্যাটাস | কারণ | এর সমাধান করুন |
|---|---|---|---|
policies.ratelimit.FailedToResolveSpikeArrestRate |
500 |
<Rate> এলিমেন্টের মধ্যে রেট সেটিং
ধারণকারী ভেরিয়েবলের রেফারেন্স Spike Arrest
পলিসির মধ্যে কোনও ভ্যালুতে রিজলভ করা না গেলে এই সমস্যা হয়। এই এলিমেন্টটি বাধ্যতামূলক এবং intpm বা intps ফর্ম্যাটে
স্পাইক অ্যারেস্ট রেট নির্দিষ্ট করতে ব্যবহার করা হয়। |
build |
policies.ratelimit.InvalidMessageWeight |
500 |
ফ্লো ভেরিয়েবলের মাধ্যমে <MessageWeight> এলিমেন্টের জন্য নির্দিষ্ট করা ভ্যালু সঠিক না হলে (পূর্ণসংখ্যা নয় এমন ভ্যালু)
এই সমস্যাটি হয়। |
build |
policies.ratelimit.SpikeArrestViolation |
429 |
রেট লিমিট পেরিয়ে গেছে। |
ডিপ্লয়মেন্ট সংক্রান্ত সমস্যা
এই নীতি থাকা কোনও প্রক্সি আপনি প্রয়োগ করলে, এই সমস্যা হতে পারে।
| সমস্যার নাম | কারণ | এর সমাধান করুন |
|---|---|---|
InvalidAllowedRate |
স্পাইক অ্যারেস্ট
নীতিতে <Rate> এলিমেন্টে স্পাইক অ্যারেস্ট রেট পূর্ণসংখ্যা না হলে অথবা রেটের শেষে ps বা pm না থাকলে,
API প্রক্সি ডেপ্লয় করা যায় না। |
build |
ফল্ট ভেরিয়েবল
রানটাইম এরর হলে এই ভেরিয়েবল সেট করা হয়। আরও তথ্যের জন্য, নীতি সংক্রান্ত সমস্যার ব্যাপারে আপনার কী জানা প্রয়োজন দেখুন।
| ভেরিয়েবল | কোথায় | উদাহরণ |
|---|---|---|
fault.name="fault_name" |
fault_name হল সমস্যার নাম, যা উপরে দেওয়া রানটাইম এরর সারণীতে তালিকাভুক্ত করা আছে। ফল্ট কোডের শেষ অংশটি হল ফল্টের নাম। | fault.name Matches "SpikeArrestViolation" |
ratelimit.policy_name.failed |
policy_name হল সেই নীতির ব্যবহারকারী-নির্দিষ্ট নাম যার কারণে সমস্যা হয়েছে। | ratelimit.SA-SpikeArrestPolicy.failed = true |
সমস্যার উত্তরের উদাহরণ
নিচে সমস্যার উত্তরের একটি উদাহরণ দেওয়া হল:
{ "fault":{ "detail":{ "errorcode":"policies.ratelimit.SpikeArrestViolation" }, "faultstring":"Spike arrest violation. Allowed rate : 10ps" } }
ভুল নিয়মের উদাহরণ
SpikeArrestViolation ফল্ট হ্যান্ডেল করার জন্য নিচে ফল্ট নিয়মের একটি উদাহরণ দেখানো হল:
<FaultRules>
<FaultRule name="Spike Arrest Errors">
<Step>
<Name>JavaScript-1</Name>
<Condition>(fault.name Matches "SpikeArrestViolation") </Condition>
</Step>
<Condition>ratelimit.Spike-Arrest-1.failed=true</Condition>
</FaultRule>
</FaultRules>কোটা বা স্পাইক অ্যারেস্ট নীতি দ্বারা সেট করা রেট সীমা অতিক্রম করার জন্য বর্তমান HTTP স্ট্যাটাস কোড
হল 429 (অত্যধিক অনুরোধ)। HTTP স্ট্যাটাস কোড পরিবর্তন করে 500
(ইন্টার্নাল সার্ভার এরর) করতে,
features.isHTTPStatusTooManyRequestEnabled প্রপার্টিকে false হিসেবে সেট করুন। এটি করতে,
সংস্থা সংক্রান্ত প্রপার্টি আপডেট করুন API ব্যবহার করুন।
যেমন:
curl -u email:password -X POST -H "Content-type:application/xml" http://api.enterprise.apigee.com/v1/organizations/myorg -d \ "<Organization type="trial" name="MyOrganization"> <Properties> <Property name="features.isHTTPStatusTooManyRequestEnabled">true</Property> . . . </Properties> </Organization>"
স্কিমা
প্রতিটি নীতির ধরন XML স্কিমা (.xsd) দ্বারা সংজ্ঞায়িত করা হয়। রেফারেন্সের জন্য, নীতি স্কিমা
GitHub-এ উপলভ্য।
সম্পর্কিত বিষয়
- কোটা সংক্রান্ত নীতি: কোটা নীতি, স্বতন্ত্র ক্লায়েন্টে ট্রাফিক সীমিত করতে
- রেট লিমিটিংয়ের জন্য রেট-লিমিটিং ওভারভিউ
- কোটা ও স্পাইকঅ্যারেস্ট নীতির তুলনা করা
- API প্রক্সির কার্যকরী নমুনা