SpikeArest की नीति

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

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

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

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

इस एलिमेंट में ये एट्रिब्यूट शामिल होते हैं, जो सभी नीतियों में शामिल हैं:

उदाहरण

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

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

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

<SpikeArrest name="Spike-Arrest-1">
  <Rate ref="request.header.runtime_rate" />
</SpikeArrest>

curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'

चाइल्ड एलिमेंट का रेफ़रंस

इस सेक्शन में, <SpikeArrest> के चाइल्ड एलिमेंट के बारे में बताया गया है.

<DisplayName>

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

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

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

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

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

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

<Identifier>

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

अनुरोध को कम करने की सुविधा को बेहतर तरीके से कंट्रोल करने के लिए, <MessageWeight> एलिमेंट के साथ इस्तेमाल करें.

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

<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> के एट्रिब्यूट के बारे में बताया गया है:

इस एलिमेंट के बारे में, 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 के वेट के साथ अनुरोध सबमिट करता है, तो उस क्लाइंट से हर मिनट में सिर्फ़ पांच मैसेज भेजने की अनुमति है, क्योंकि हर अनुरोध की गिनती दो के तौर पर की जाती है.

<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> के एट्रिब्यूट के बारे में बताया गया है:

<Rate>

यह दर तय करता है कि ट्रैफ़िक के स्पाइक (या बर्स्ट) को किस दर से सीमित किया जाए. इसके लिए, हर मिनट या हर सेकंड के इंटरवल में अनुमति वाले अनुरोधों की संख्या सेट की जाती है. इस एलिमेंट का इस्तेमाल, <Identifier> और <MessageWeight> के साथ भी किया जा सकता है. इससे क्लाइंट से वैल्यू स्वीकार करके, रनटाइम के दौरान ट्रैफ़िक को आसानी से कम किया जा सकता है.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
</SpikeArrest>

<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> के एट्रिब्यूट के बारे में बताया गया है:

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

<UseEffectiveCount>

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

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

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

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

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

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

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

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

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

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

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

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

गड़बड़ी का रेफ़रंस

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

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

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

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

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

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

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

गड़बड़ी के रिस्पॉन्स का उदाहरण

यहां गड़बड़ी के रिस्पॉन्स का उदाहरण दिया गया है:

{  
   "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 पर सेट करें. इसके लिए, Update organization properties 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>"

स्कीमा

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

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

• कोटा नीति: कोटा नीति, जिससे अलग-अलग क्लाइंट पर ट्रैफ़िक को सीमित किया जा सके
• अनुरोध की संख्या सीमित करने की सुविधा के बारे में खास जानकारी पाने के लिए, अनुरोध की संख्या सीमित करना
• कोटा और स्पाइकअरेस्ट की नीतियों की तुलना करना
• एपीआई प्रॉक्सी के काम करने वाले सैंपल