SpikeArest की नीति

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

Edge यूज़र इंटरफ़ेस (यूआई) में स्पाइक अरेस्ट का आइकॉन

स्पाइक अरेस्ट नीति, <Rate> एलिमेंट की मदद से, ट्रैफ़िक में अचानक होने वाली बढ़ोतरी से सुरक्षा करती है. यह एलिमेंट, एपीआई प्रॉक्सी से प्रोसेस किए गए अनुरोधों की संख्या को सीमित करता है. साथ ही, उन्हें बैकएंड में भेजता है. इससे परफ़ॉर्मेंस में होने वाली देरी और डाउनटाइम से सुरक्षा मिलती है.

<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 के यूज़र इंटरफ़ेस (यूआई) में अपने फ़्लो में स्पाइक अरेस्ट की नीति जोड़ने पर, डिफ़ॉल्ट सेटिंग दिखाई गई हैं:

<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 लागू नहीं ज़रूरी

नीति का अंदरूनी नाम. name एट्रिब्यूट की वैल्यू में अक्षर, संख्याएं, स्पेस, हाइफ़न, अंडरस्कोर, और फ़ुल स्टॉप का इस्तेमाल किया जा सकता है. इस वैल्यू में 255 से ज़्यादा वर्ण नहीं हो सकते.

इसके अलावा, मैनेजमेंट एलिमेंट के यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में, नीति एलिमेंट को किसी अलग नाम से इस्तेमाल करने के लिए, <DisplayName> एलिमेंट का इस्तेमाल किया जा सकता है.
continueOnError गलत ज़रूरी नहीं नीति के काम न करने पर गड़बड़ी दिखाने के लिए, "गलत" पर सेट करें. ज़्यादातर नीतियों के लिए इस तरीके का इस्तेमाल किया जाना चाहिए. नीति लागू न होने के बाद भी फ़्लो चलाने के लिए, "सही" पर सेट करें.
enabled सही ज़रूरी नहीं नीति लागू करने के लिए, "सही" पर सेट करें. नीति को "बंद" करने के लिए "गलत" पर सेट करें. अगर नीति किसी फ़्लो से जुड़ी हुई हो, तो भी उसे लागू नहीं किया जाएगा.
async   गलत बहिष्कृत इस एट्रिब्यूट के इस्तेमाल पर रोक लगा दी गई है.

उदाहरण

यहां कुछ उदाहरण दिए गए हैं, जिनसे पता चलता है कि स्पाइक अरेस्ट की नीति का इस्तेमाल कैसे किया जा सकता है:

उदाहरण 1

यहां दिए गए उदाहरण में, हर सेकंड में पांच अनुरोध करने की दर सेट की गई है:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

इस नीति के तहत, हर 200 मिलीसेकंड में एक अनुरोध किया जा सकता है. इसका मतलब है कि हर सेकंड में पांच अनुरोध किए जा सकते हैं.

उदाहरण 2

यहां दिए गए उदाहरण में, हर मिनट के लिए दर को 300 पर सेट किया गया है:

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

इफ़ेक्टिव रेट 300pm है. इसका मतलब है कि हर 200 मिलीसेकंड में बकेट में एक नया टोकन जोड़ा जाता है. बकेट का साइज़ हमेशा messagesPerPeriod का 10% होता है. इसलिए, 300 के messagesPerPeriod के साथ, बकेट का साइज़ 30 टोकन होता है.

उदाहरण 3

यहां दिए गए उदाहरण में, हर मिनट में 12 अनुरोधों की सीमा तय की गई है. इसका मतलब है कि हर पांच सेकंड में एक अनुरोध किया जा सकता है या 60/12 अनुरोध किए जा सकते हैं:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

इसके अलावा, <MessageWeight> एलिमेंट, कस्टम वैल्यू (weight हेडर) स्वीकार करता है. यह वैल्यू, खास ऐप्लिकेशन या क्लाइंट के लिए मैसेज के वेट को अडजस्ट करती है. इससे, <Identifier> एलिमेंट से पहचाने गए इकाइयों के लिए थ्रॉटलिंग पर अतिरिक्त कंट्रोल मिलता है.

चौथा उदाहरण

यहां दिए गए उदाहरण में, स्पाइक अरेस्ट को अनुरोध के ज़रिए सेट की गई रनटाइम वैल्यू को देखने का निर्देश दिया गया है. इस वैल्यू को 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>

इस एट्रिब्यूट का इस्तेमाल name एट्रिब्यूट के साथ किया जाता है. इससे, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) के प्रॉक्सी एडिटर में नीति को लेबल किया जा सकता है. इसके लिए, किसी दूसरे नाम का इस्तेमाल किया जाता है, जो ज़्यादा स्वाभाविक लगता है.

<DisplayName> एलिमेंट, सभी नीतियों में शामिल होता है.

डिफ़ॉल्ट वैल्यू लागू नहीं
ज़रूरी है? ज़रूरी नहीं. <DisplayName> को शामिल न करने पर, नीति के name एट्रिब्यूट की वैल्यू का इस्तेमाल किया जाता है
समस्या स्ट्रिंग
पैरंट एलिमेंट <PolicyElement>
चाइल्ड एलिमेंट कोई नहीं

<DisplayName> एलिमेंट में इस सिंटैक्स का इस्तेमाल किया जाता है:

सिंटैक्स

<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>

उदाहरण

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

<DisplayName> एलिमेंट में कोई एट्रिब्यूट या चाइल्ड एलिमेंट नहीं है.

<Identifier>

इस कुकी की मदद से, अनुरोधों को ग्रुप करने का तरीका चुना जा सकता है, ताकि क्लाइंट के आधार पर स्पाइक अरेस्ट नीति लागू की जा सके. उदाहरण के लिए, डेवलपर आईडी के हिसाब से अनुरोधों को ग्रुप किया जा सकता है. ऐसे में, हर डेवलपर के अनुरोधों को, स्पाइक अरेस्ट रेट में गिना जाएगा. प्रॉक्सी के सभी अनुरोधों को नहीं गिना जाएगा.

अनुरोध थ्रॉटलिंग पर ज़्यादा बेहतर कंट्रोल के लिए, <MessageWeight> एलिमेंट के साथ इसका इस्तेमाल करें.

अगर आपने <Identifier> एलिमेंट को खाली छोड़ दिया है, तो उस एपीआई प्रॉक्सी में किए गए सभी अनुरोधों के लिए, एक ही दर सीमा लागू होगी.

डिफ़ॉल्ट वैल्यू लागू नहीं
ज़रूरी है? वैकल्पिक
समस्या स्ट्रिंग
पैरंट एलिमेंट <SpikeArrest>
चाइल्ड एलिमेंट कोई नहीं

सिंटैक्स

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Identifier ref="flow_variable"/>
</SpikeArrest>

उदाहरण 1

यहां दिए गए उदाहरण में, हर डेवलपर आईडी के लिए स्पाइक अरेस्ट की नीति लागू की गई है:

<SpikeArrest name="Spike-Arrest-1">
  <Identifier ref="developer.id"/>
  <Rate>42pm</Rate/>
</SpikeArrest>

यहां दी गई टेबल में, <Identifier> एट्रिब्यूट के बारे में बताया गया है:

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
ref इस कुकी से उस वैरिएबल की पहचान होती है जिसके हिसाब से स्पाइक अरेस्ट, आने वाले अनुरोधों को ग्रुप करता है. किसी यूनीक क्लाइंट को दिखाने के लिए, किसी भी फ़्लो वैरिएबल का इस्तेमाल किया जा सकता है. जैसे, VerifyAPIKey नीति के साथ उपलब्ध वैरिएबल. JavaScript नीति या AssignMessage नीति का इस्तेमाल करके भी कस्टम वैरिएबल सेट किए जा सकते हैं. लागू नहीं ज़रूरी है

इस एलिमेंट के बारे में, Apigee कम्यूनिटी की इस पोस्ट में भी बताया गया है: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<MessageWeight>

इससे हर मैसेज के लिए तय किए गए वेटिंग की जानकारी मिलती है. मैसेज के वज़न से, स्पाइक अरेस्ट रेट के हिसाब पर किसी एक अनुरोध का असर बदल जाता है. मैसेज का वेट, कोई भी फ़्लो वैरिएबल हो सकता है. जैसे, एचटीटीपी हेडर, क्वेरी पैरामीटर, फ़ॉर्म पैरामीटर या मैसेज के मुख्य हिस्से का कॉन्टेंट. JavaScript नीति या AssignMessage नीति का इस्तेमाल करके भी कस्टम वैरिएबल का इस्तेमाल किया जा सकता है.

<Identifier> के साथ इसका इस्तेमाल करके, खास क्लाइंट या ऐप्लिकेशन से मिलने वाले अनुरोधों को और थ्रॉटल किया जा सकता है.

उदाहरण के लिए, अगर स्पाइक अरेस्ट <Rate> 10pm है और कोई ऐप्लिकेशन 2 के वेट वाले अनुरोध सबमिट करता है, तो उस क्लाइंट को हर मिनट सिर्फ़ पांच मैसेज भेजने की अनुमति होगी, क्योंकि हर अनुरोध को 2 के तौर पर गिना जाता है.

डिफ़ॉल्ट वैल्यू लागू नहीं
ज़रूरी है? वैकल्पिक
समस्या पूर्णांक
पैरंट एलिमेंट <SpikeArrest>
चाइल्ड एलिमेंट कोई नहीं

सिंटैक्स

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <MessageWeight ref="flow_variable"/>
</SpikeArrest>

उदाहरण 1

यहां दिए गए उदाहरण में, हर मिनट में 12 अनुरोधों की सीमा तय की गई है. इसका मतलब है कि हर पांच सेकंड में एक अनुरोध किया जा सकता है या 60/12 अनुरोध किए जा सकते हैं:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

इस उदाहरण में, <MessageWeight> कस्टम वैल्यू (अनुरोध में मौजूद weight हेडर) स्वीकार करता है. इससे, खास क्लाइंट के लिए मैसेज के वेट को अडजस्ट किया जाता है. इससे, <Identifier> एलिमेंट से पहचाने गए इकाइयों के लिए थ्रॉटलिंग पर अतिरिक्त कंट्रोल मिलता है.

यहां दी गई टेबल में, <MessageWeight> एट्रिब्यूट के बारे में बताया गया है:

एट्रिब्यूट ब्यौरा मौजूदगी डिफ़ॉल्ट
ref उस फ़्लो वैरिएबल की पहचान करता है जिसमें किसी क्लाइंट के लिए मैसेज का वज़न शामिल होता है. यह कोई भी फ़्लो वैरिएबल हो सकता है. जैसे, एचटीटीपी क्वेरी पैरामीटर, हेडर या मैसेज बॉडी का कॉन्टेंट. ज़्यादा जानकारी के लिए, फ़्लो वैरिएबल का रेफ़रंस देखें. 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 की वैल्यू, पॉज़िटिव और नॉन-ज़ीरो पूर्णांक होनी चाहिए.

उदाहरण 1

यहां दिए गए उदाहरण में, हर सेकंड में पांच अनुरोधों की दर सेट की गई है:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

इस नीति के तहत, हर 200 मिलीसेकंड में एक अनुरोध किया जा सकता है. इसका मतलब है कि हर सेकंड में पांच अनुरोध किए जा सकते हैं.

उदाहरण 2

यहां दिए गए उदाहरण में, हर मिनट में 12 अनुरोधों की दर सेट की गई है:

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

इस उदाहरण में, नीति के तहत हर पांच सेकंड में एक अनुरोध किया जा सकता है (60/12).

यहां दी गई टेबल में, <Rate> एट्रिब्यूट के बारे में बताया गया है:

एट्रिब्यूट ब्यौरा मौजूदगी डिफ़ॉल्ट
ref यह फ़्लो वैरिएबल की पहचान करता है, जो दर के बारे में बताता है. यह कोई भी फ़्लो वैरिएबल हो सकता है. जैसे, एचटीटीपी क्वेरी पैरामीटर, हेडर या मैसेज बॉडी का कॉन्टेंट या कोई वैल्यू. जैसे, केवीएम. ज़्यादा जानकारी के लिए, फ़्लो वैरिएबल का रेफ़रंस देखें.

JavaScript नीति या AssignMessage नीति का इस्तेमाल करके, कस्टम वैरिएबल भी इस्तेमाल किए जा सकते हैं.

अगर आपने ref और इस एलिमेंट का मुख्य हिस्सा, दोनों तय किए हैं, तो ref की वैल्यू लागू होगी. साथ ही, जब अनुरोध में फ़्लो वैरिएबल सेट किया जाता है, तब ref की वैल्यू को प्राथमिकता दी जाती है. (अगर अनुरोध में ref में पहचाना गया वैरिएबल सेट नहीं किया गया है, तो यह स्थिति उलट जाती है.)

उदाहरण के लिए:

<Rate ref="request.header.custom_rate">1pm</Rate>

इस उदाहरण में, अगर क्लाइंट "custom_rate" हेडर पास नहीं करता है, तो सभी क्लाइंट के लिए एपीआई प्रॉक्सी की दर, हर मिनट में एक अनुरोध होगी. अगर क्लाइंट "custom_rate" हेडर पास करता है, तो प्रॉक्सी पर मौजूद सभी क्लाइंट के लिए, दर की सीमा एक सेकंड में 10 अनुरोध हो जाती है. ऐसा तब तक होता है, जब तक "custom_rate" हेडर के बिना कोई अनुरोध नहीं भेजा जाता.

<Identifier> का इस्तेमाल करके, अनुरोधों को ग्रुप किया जा सकता है. इससे अलग-अलग तरह के क्लाइंट के लिए, कस्टम दरें लागू की जा सकती हैं.

अगर आपने ref के लिए कोई वैल्यू तय की है, लेकिन <Rate> एलिमेंट के मुख्य हिस्से में दर सेट नहीं की है और क्लाइंट कोई वैल्यू पास नहीं करता है, तो स्पाइक अरेस्ट की नीति के तहत गड़बड़ी दिखेगी.

 वैकल्पिक लागू नहीं

<UseEffectiveCount>

ऑटो-स्केलिंग ग्रुप का इस्तेमाल करते समय, यह कुकी आपके स्पाइक अरेस्ट की संख्या को मैसेज प्रोसेसर (एमपी) में बांटती है.

सिंटैक्स

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

उदाहरण 1

यहां दिए गए उदाहरण में, <UseEffectiveCount> को सही पर सेट करने का तरीका बताया गया है:

<SpikeArrest name='Spike-Arrest-1'>
  <Rate>40ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

<UseEffectiveCount> एलिमेंट ज़रूरी नहीं है. अगर स्पाइक अरेस्ट करने की नीति में इस एलिमेंट को शामिल नहीं किया जाता है, तो इसकी डिफ़ॉल्ट वैल्यू false होती है.

डिफ़ॉल्ट वैल्यू गलत
ज़रूरी है? वैकल्पिक
समस्या बूलियन
पैरंट एलिमेंट <SpikeArrest>
चाइल्ड एलिमेंट कोई नहीं

यहां दी गई टेबल में, <UseEffectiveCount> एलिमेंट के एट्रिब्यूट के बारे में बताया गया है:

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
ref उस वैरिएबल की पहचान करता है जिसमें <UseEffectiveCount> की वैल्यू शामिल होती है. यह कोई भी फ़्लो वैरिएबल हो सकता है. जैसे, एचटीटीपी क्वेरी पैरामीटर, हेडर या मैसेज बॉडी का कॉन्टेंट. ज़्यादा जानकारी के लिए, फ़्लो वैरिएबल का रेफ़रंस देखें. JavaScript नीति या AssignMessage नीति का इस्तेमाल करके, कस्टम वैरिएबल भी सेट किए जा सकते हैं. लागू नहीं वैकल्पिक

<UseEffectiveCount> का असर, इसकी वैल्यू पर निर्भर करता है:

  • true: किसी एमपी के स्पाइक रेट की सीमा, <Rate> को एक ही पॉड में मौजूद एमपी की मौजूदा संख्या से भाग देने पर मिलती है. कुल सीमा, <Rate> की वैल्यू है. जब एमपी को डाइनैमिक तरीके से जोड़ा (या हटाया) जाता है, तो उनकी अलग-अलग स्पाइक रेट की सीमाएं बढ़ (या घट) जाएंगी. हालांकि, कुल सीमा वही रहेगी.
  • false: हर एमपी के लिए, स्पाइक रेट की सीमा, उसके <Rate> की वैल्यू होती है. कुल सीमा, सभी एमपी की दरों का योग होती है. एमपी जोड़ने (या हटाने) पर, उनकी व्यक्तिगत स्पाइक रेट की सीमाएं वही रहेंगी. हालांकि, कुल सीमा बढ़ जाएगी (या कम हो जाएगी).

SpikeArrest नीति, "टोकन बकेट" एल्गोरिदम का इस्तेमाल करती है. यह एल्गोरिदम, ट्रैफ़िक में अचानक होने वाली बढ़ोतरी को कम करता है. इसके लिए, यह आपकी तय की गई दर की सीमा को छोटे-छोटे इंटरवल में बांट देता है. इस तरीके की एक समस्या यह है कि कम समय में किए गए कई ऐसे अनुरोधों को अस्वीकार किया जा सकता है जो सही हैं.

उदाहरण के लिए, मान लें कि आपने 30pm (हर मिनट में 30 अनुरोध) की दर डाली है. जांच के दौरान, आपको लग सकता है कि एक मिनट के अंदर 30 अनुरोध भेजे जा सकते हैं. हालांकि, नीति के तहत सेटिंग लागू करने का यह तरीका नहीं है. अगर इस बारे में सोचा जाए, तो एक सेकंड में 30 अनुरोधों को कुछ एनवायरमेंट में मिनी स्पाइक माना जा सकता है.

  • प्रति मिनट की दर को सेकंड के इंटरवल में अनुमति दिए गए पूरे अनुरोधों में बदल दिया जाता है.

    उदाहरण के लिए, 30 अनुरोध प्रति मिनट को इस तरह से बांटा जाता है:
    60 सेकंड (1 मिनट) / 30 अनुरोध प्रति मिनट = हर दो सेकंड में एक अनुरोध या हर दो सेकंड में एक अनुरोध की अनुमति है. दो सेकंड के अंदर किया गया दूसरा अनुरोध पूरा नहीं होगा. इसके अलावा, एक मिनट में 31वां अनुरोध करने पर, उसे पूरा नहीं किया जा सकेगा.

  • प्रति सेकंड की दर को, मिलीसेकंड के इंटरवल में अनुमति दिए गए पूरे अनुरोधों में बदल दिया जाता है.

    उदाहरण के लिए, 10ps को इस तरह से स्मूथ किया जाता है:
    1000 मिलीसेकंड (1 सेकंड) / 10ps = 100 मिलीसेकंड के अंतराल या हर 100 मिलीसेकंड में एक अनुरोध की अनुमति. 100 मि॰से॰ के अंदर किया गया दूसरा अनुरोध पूरा नहीं होगा. इसके अलावा, एक सेकंड में 11वां अनुरोध करने पर भी अनुरोध पूरा नहीं होगा.

नीचे दी गई टेबल में, हर एमपी की असरदार रेट लिमिट पर <UseEffectiveCount> के असर को दिखाया गया है:

<UseEffectiveCount> की वैल्यू
false false false true true true
सांसदों की संख्या 8 4 2 8 4 2
<Rate> की वैल्यू 10 10 10 40 40 40
प्रति एमपी के हिसाब से लागू दर 10 10 10 5 10 20
कुल सीमा 80 40 20 40* 40* 40*
* <Rate> के बराबर.

इस उदाहरण में ध्यान दें कि जब एमपी की संख्या को 4 से घटाकर 2 कर दिया जाता है और <UseEffectiveCount> false होता है, तो हर एमपी के लिए असरदार दर वही रहती है (10 पर). हालांकि, जब <UseEffectiveCount> true होता है, तो एमपी की संख्या 4 से 2 होने पर, हर एमपी के लिए प्रभावी दर 10 से 20 हो जाती है.

<Rate>

फ़्लो वैरिएबल

जब स्पाइक अरेस्ट नीति लागू होती है, तो यह फ़्लो वैरिएबल भर जाता है:

वैरिएबल टाइप अनुमति ब्यौरा
ratelimit.policy_name.failed बूलियन रीड-ओनली इससे पता चलता है कि नीति का पालन नहीं किया गया है (true या false).

ज़्यादा जानकारी के लिए, फ़्लो वैरिएबल का रेफ़रंस देखें.

गड़बड़ी की जानकारी

इस सेक्शन में, गड़बड़ी के कोड और गड़बड़ी के मैसेज के साथ-साथ गड़बड़ी के वैरिएबल के बारे में बताया गया है ये सेटिंग, Edge की मदद से सेट की जाती हैं. ऐसा तब होता है, जब इस नीति की वजह से कोई गड़बड़ी होती है. यह जानकारी जानना ज़रूरी है कि क्या आप गड़बड़ियों को ठीक करता है. इस बारे में ज़्यादा जानने के लिए, यह देखें आपके लिए काम की जानकारी नीति से जुड़ी गड़बड़ियों और हैंडलिंग के बारे में जानकारी गलतियां.

रनटाइम की गड़बड़ियां

नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.

गड़बड़ी कोड एचटीटीपी कोड स्थिति वजह ठीक करें
policies.ratelimit.FailedToResolveSpikeArrestRate 500 यह गड़बड़ी तब होती है, जब रेट सेटिंग वाले वैरिएबल का रेफ़रंस होता है <Rate> एलिमेंट के अंदर, Spike Arrest में मौजूद वैल्यू नहीं हटाई जा सकती की नीति देखें. यह एलिमेंट ज़रूरी है. इसका इस्तेमाल, गिरफ़्तारी की दर के बारे में बताने के लिए किया जाता है intpm या intps का फ़ॉर्मैट.
policies.ratelimit.InvalidMessageWeight 500 यह गड़बड़ी तब होती है, जब <MessageWeight> एलिमेंट के लिए वैल्यू इसके ज़रिए तय की जाती है फ़्लो वैरिएबल अमान्य है (गैर-पूर्णांक मान).
policies.ratelimit.SpikeArrestViolation 429

दर सीमा पार हो गई थी.

डिप्लॉयमेंट से जुड़ी गड़बड़ियां

ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाली प्रॉक्सी को डिप्लॉय किया जाता है.

गड़बड़ी का नाम वजह ठीक करें
InvalidAllowedRate अगर स्पाइक अरेस्ट के <Rate> एलिमेंट में, गिरफ़्तारी की ज़्यादा दर बताई गई है, तो नीति कोई पूर्णांक नहीं है या अगर दर में सफ़िक्स के तौर पर ps या pm नहीं है, तो तब एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता.

गड़बड़ी के वैरिएबल

रनटाइम की गड़बड़ी होने पर ये वैरिएबल सेट किए जाते हैं. ज़्यादा जानकारी के लिए, आपके लिए ज़रूरी जानकारी देखें नीति से जुड़ी गड़बड़ियों के बारे में जानकारी.

वैरिएबल कहां उदाहरण
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>

कोटा या स्पाइक अरेस्ट नीति के तहत तय की गई दर की सीमा से ज़्यादा अनुरोध करने पर, मौजूदा एचटीटीपी स्टेटस कोड 429 (बहुत ज़्यादा अनुरोध) है. एचटीटीपी स्टेटस कोड को 500 (इंटरनल सर्वर की गड़बड़ी) में बदलने के लिए, संगठन की प्रॉपर्टी अपडेट करें एपीआई का इस्तेमाल करके, features.isHTTPStatusTooManyRequestEnabled प्रॉपर्टी को false पर सेट करें.

उदाहरण के लिए:

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>"

स्कीमा

नीति के हर टाइप को एक्सएमएल स्कीमा (.xsd) से तय किया जाता है. रेफ़रंस के लिए, नीति के स्कीमा GitHub पर उपलब्ध हैं.

मिलते-जुलते विषय