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

स्पाइक अरेस्ट नीति, <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 |
लागू नहीं | ज़रूरी |
नीति का अंदरूनी नाम. इसके अलावा, मैनेजमेंट एलिमेंट के यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में, नीति एलिमेंट को किसी अलग नाम से इस्तेमाल करने के लिए, |
continueOnError |
गलत | ज़रूरी नहीं | नीति के काम न करने पर गड़बड़ी दिखाने के लिए, "गलत" पर सेट करें. ज़्यादातर नीतियों के लिए इस तरीके का इस्तेमाल किया जाना चाहिए. नीति लागू न होने के बाद भी फ़्लो चलाने के लिए, "सही" पर सेट करें. |
enabled |
सही | ज़रूरी नहीं | नीति लागू करने के लिए, "सही" पर सेट करें. नीति को "बंद" करने के लिए "गलत" पर सेट करें. अगर नीति किसी फ़्लो से जुड़ी हुई हो, तो भी उसे लागू नहीं किया जाएगा. |
async |
गलत | बहिष्कृत | इस एट्रिब्यूट के इस्तेमाल पर रोक लगा दी गई है. |
उदाहरण
यहां कुछ उदाहरण दिए गए हैं, जिनसे पता चलता है कि स्पाइक अरेस्ट की नीति का इस्तेमाल कैसे किया जा सकता है:
उदाहरण 1
यहां दिए गए उदाहरण में, हर सेकंड में पांच अनुरोधों की दर सेट की गई है:
<SpikeArrest name="Spike-Arrest-1"> <Rate>5ps</Rate> </SpikeArrest>
इस नीति के तहत, हर 200 मिलीसेकंड में एक अनुरोध किया जा सकता है. यह दर 1000/5 है.
उदाहरण 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 मिलीसेकंड में एक अनुरोध किया जा सकता है. यह दर 1000/5 है.
उदाहरण 2
यहां दिए गए उदाहरण में, हर मिनट में 12 अनुरोधों की दर सेट की गई है:
<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast"> <DisplayName>SpikeArreast</DisplayName> <Rate>300pm</Rate> </SpikeArrest>
इस उदाहरण में, नीति के तहत हर पांच सेकंड में एक अनुरोध करने की अनुमति दी गई है (60/12).
यहां दी गई टेबल में, <Rate>
एट्रिब्यूट के बारे में बताया गया है:
एट्रिब्यूट | ब्यौरा | मौजूदगी | डिफ़ॉल्ट |
---|---|---|---|
ref |
यह फ़्लो वैरिएबल की पहचान करता है, जो दर के बारे में बताता है. यह कोई भी फ़्लो वैरिएबल हो सकता है. जैसे, एचटीटीपी क्वेरी पैरामीटर, हेडर या मैसेज बॉडी का कॉन्टेंट या कोई वैल्यू. जैसे, केवीएम. ज़्यादा जानकारी के लिए, फ़्लो वैरिएबल का रेफ़रंस देखें.
JavaScript नीति या AssignMessage नीति का इस्तेमाल करके, कस्टम वैरिएबल भी इस्तेमाल किए जा सकते हैं. अगर आपने उदाहरण के लिए: <Rate ref="request.header.custom_rate">1pm</Rate> इस उदाहरण में, अगर क्लाइंट "custom_rate" हेडर पास नहीं करता है, तो सभी क्लाइंट के लिए एपीआई प्रॉक्सी की दर, हर मिनट में एक अनुरोध होगी. अगर क्लाइंट "custom_rate" हेडर पास करता है, तो प्रॉक्सी पर मौजूद सभी क्लाइंट के लिए, दर की सीमा एक सेकंड में 10 अनुरोध हो जाती है. ऐसा तब तक होता है, जब तक "custom_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 हो जाती है.
फ़्लो वैरिएबल
जब स्पाइक अरेस्ट नीति लागू होती है, तो यह फ़्लो वैरिएबल पॉप्युलेट होता है:
वैरिएबल | टाइप | अनुमति | ब्यौरा |
---|---|---|---|
ratelimit.policy_name.failed |
बूलियन | रीड-ओनली | इससे पता चलता है कि नीति का पालन नहीं किया गया है (true या
false ). |
ज़्यादा जानकारी के लिए, फ़्लो वैरिएबल का रेफ़रंस देखें.
गड़बड़ी की जानकारी
इस सेक्शन में, गड़बड़ी के कोड और गड़बड़ी के मैसेज के साथ-साथ गड़बड़ी के वैरिएबल के बारे में बताया गया है ये सेटिंग, Edge की मदद से सेट की जाती हैं. ऐसा तब होता है, जब इस नीति की वजह से कोई गड़बड़ी होती है. यह जानकारी जानना ज़रूरी है कि क्या आप गड़बड़ियों को ठीक करता है. इस बारे में ज़्यादा जानने के लिए, यह देखें आपके लिए काम की जानकारी नीति से जुड़ी गड़बड़ियों और हैंडलिंग के बारे में जानकारी गलतियां.
रनटाइम की गड़बड़ियां
नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.
गड़बड़ी कोड | एचटीटीपी कोड स्थिति | वजह | ठीक करें |
---|---|---|---|
policies.ratelimit.FailedToResolveSpikeArrestRate |
500 |
यह गड़बड़ी तब होती है, जब रेट सेटिंग वाले वैरिएबल का रेफ़रंस होता है
<Rate> एलिमेंट के अंदर, Spike Arrest में मौजूद वैल्यू नहीं हटाई जा सकती
की नीति देखें. यह एलिमेंट ज़रूरी है. इसका इस्तेमाल, गिरफ़्तारी की दर के बारे में बताने के लिए किया जाता है
intpm या intps का फ़ॉर्मैट. |
build |
policies.ratelimit.InvalidMessageWeight |
500 |
यह गड़बड़ी तब होती है, जब <MessageWeight> एलिमेंट के लिए वैल्यू इसके ज़रिए तय की जाती है
फ़्लो वैरिएबल अमान्य है (गैर-पूर्णांक मान). |
build |
policies.ratelimit.SpikeArrestViolation |
429 |
दर सीमा पार हो गई थी. |
डिप्लॉयमेंट से जुड़ी गड़बड़ियां
ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाली प्रॉक्सी को डिप्लॉय किया जाता है.
गड़बड़ी का नाम | वजह | ठीक करें |
---|---|---|
InvalidAllowedRate |
अगर स्पाइक अरेस्ट के <Rate> एलिमेंट में, गिरफ़्तारी की ज़्यादा दर बताई गई है, तो
नीति कोई पूर्णांक नहीं है या अगर दर में सफ़िक्स के तौर पर ps या pm नहीं है, तो
तब एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता. |
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>
कोटा या स्पाइक अरेस्ट नीति के तहत तय की गई दर की सीमा से ज़्यादा अनुरोध करने पर, मौजूदा एचटीटीपी स्टेटस कोड 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 पर उपलब्ध हैं.
मिलते-जुलते विषय
- कोटा नीति: कोटा नीति, ताकि अलग-अलग क्लाइंट पर ट्रैफ़िक को सीमित किया जा सके
- दर सीमित करने की खास जानकारी के लिए, दर सीमित करना लेख पढ़ें
- कोटा और SpikeArrest नीतियों की तुलना करना
- एपीआई प्रॉक्सी के वर्किंग सैंपल