responseCache की नीति

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

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

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

सामान्य मकसद के लिए कम समय तक कैश मेमोरी में डेटा सेव करने के लिए, Populate Cache नीति का इस्तेमाल करें. इस नीति का इस्तेमाल, लुकअप कैश मेमोरी की नीति (कैश मेमोरी की एंट्री पढ़ने के लिए) और कैश मेमोरी अमान्य करने की नीति (एंट्री अमान्य करने के लिए) के साथ किया जाता है.

रिस्पॉन्स कैश मेमोरी की नीति के बारे में जानने के लिए, यह वीडियो देखें.

सैंपल

10 मिनट की कैश मेमोरी

इस उदाहरण में बताया गया है कि कैश मेमोरी में सेव किए गए जवाबों को 10 मिनट तक कैसे सेव रखा जाता है.

मान लें कि आपके पास इस यूआरएल पर एक एपीआई है:

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

आपने क्वेरी पैरामीटर w का इस्तेमाल कैश मेमोरी की कुंजी के तौर पर किया है. Apigee Edge, अनुरोध मिलने पर क्वेरी पैरामीटर w की वैल्यू की जांच करता है. अगर कैश मेमोरी में मान्य (यानी कि जिसकी समयसीमा खत्म नहीं हुई है) जवाब मौजूद है, तो कैश मेमोरी में सेव किया गया जवाब, अनुरोध करने वाले क्लाइंट को भेज दिया जाता है.

अब मान लें कि आपने ResponseCache नीति को इस तरह कॉन्फ़िगर किया है.

<ResponseCache name="ResponseCache">
    <CacheKey>
        <KeyFragment ref="request.queryparam.w" />
    </CacheKey>
    <ExpirySettings>
        <TimeoutInSeconds>600</TimeoutInSeconds>
    </ExpirySettings>
</ResponseCache>

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

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

कैश लुकअप की सुविधा छोड़ें

यहां दिए गए उदाहरण में, कैश मेमोरी में मौजूद डेटा को खोजने की प्रोसेस को स्किप करने और कैश मेमोरी को रीफ़्रेश करने का तरीका बताया गया है. SkipCacheLookup के इस्तेमाल के बारे में जानने के लिए, यह वीडियो भी देखें.

अनुरोध के पाथ में, SkipCacheLookup की ज़रूरी नहीं वाली शर्त (अगर कॉन्फ़िगर की गई है) का आकलन किया जाता है. अगर शर्त पूरी होती है, तो कैश मेमोरी में मौजूद डेटा को नहीं देखा जाता और कैश मेमोरी को रीफ़्रेश कर दिया जाता है.

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

उदाहरण के लिए, मान लें कि एपीआई को इस यूआरएल पर कॉल किया गया है:

'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"

अब मान लें कि उस प्रॉक्सी पर यह ResponseCache नीति कॉन्फ़िगर की गई है. ध्यान दें कि bypass-cache की स्थिति को सही पर सेट किया गया है.

<ResponseCache name="ResponseCache">
    <CacheKey>
        <KeyFragment ref="request.queryparam.w" />
    </CacheKey>
    <!-- Explicitly refresh the cached response -->
    <SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
    <ExpirySettings>
        <TimeoutInSeconds>600</TimeoutInSeconds>
    </ExpirySettings>
</ResponseCache>

शर्तों के बारे में ज़्यादा जानने के लिए, फ़्लो वैरिएबल और शर्तें लेख पढ़ें.

एलिमेंट का रेफ़रंस

एलिमेंट रेफ़रंस में, नीति के एलिमेंट और एट्रिब्यूट के बारे में बताया जाता है.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
    <DisplayName>Response Cache 1</DisplayName>
    <Properties/>
    <CacheKey>
        <Prefix/>
        <KeyFragment ref="request.uri" />
    </CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
        <ExpiryDate/>
        <TimeOfDay/>
        <TimeoutInSeconds ref="flow.variable.here">300</TimeoutInSeconds>
    </ExpirySettings>
    <CacheResource>cache_to_use</CacheResource>
    <CacheLookupTimeoutInSeconds/>
    <ExcludeErrorResponse/>
    <SkipCacheLookup/>
    <SkipCachePopulation/>
    <UseAcceptHeader/>
    <UseResponseCacheHeaders/>
</ResponseCache>

<ResponseCache> एट्रिब्यूट

<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">

यहां दी गई टेबल में, ऐसे एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट में एक जैसे होते हैं:

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी
name

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

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

 लागू नहीं ज़रूरी है
continueOnError

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

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

 गलत वैकल्पिक
enabled

नीति को लागू करने के लिए, true पर सेट करें.

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

 सही वैकल्पिक
async

यह एट्रिब्यूट अब काम नहीं करता.

 गलत बहिष्कृत

&lt;DisplayName&gt; एलिमेंट

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

<DisplayName>Policy Display Name</DisplayName>
डिफ़ॉल्ट

लागू नहीं

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

<CacheKey> एलिमेंट

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

कैश कुंजियों का साइज़ 2 केबी से ज़्यादा नहीं होना चाहिए.

<CacheKey>
    <Prefix>string</Prefix>
    <KeyFragment ref="variable_name" />
    <KeyFragment>literal_string</KeyFragment>
</CacheKey>

डिफ़ॉल्ट:

लागू नहीं

मौजूदगी:

 ज़रूरी है

टाइप:

लागू नहीं

<CacheKey>, कैश में सेव किए गए डेटा के हर हिस्से का नाम बनाता है. कुंजी को अक्सर इकाई के हेडर या क्वेरी पैरामीटर से मिली वैल्यू का इस्तेमाल करके सेट किया जाता है. ऐसे मामलों में, आपको एलिमेंट के ref एट्रिब्यूट में, कुंजी वैल्यू वाला वैरिएबल तय करना होगा.

रनटाइम के दौरान, <KeyFragment> वैल्यू के आगे <Scope> एलिमेंट की वैल्यू या <Prefix> वैल्यू जोड़ी जाती है. उदाहरण के लिए, इससे UserToken__apiAccessToken__<value_of_client_id> के तौर पर कैश मेमोरी की कुंजी मिलती है:

<CacheKey>
    <Prefix>UserToken</Prefix>
    <KeyFragment>apiAccessToken</KeyFragment>
    <KeyFragment ref="request.queryparam.client_id" />
</CacheKey>

<Prefix> और <Scope> के साथ <CacheKey> एलिमेंट का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, कैश मेमोरी की कुंजियों का इस्तेमाल करना लेख पढ़ें.

<CacheLookupTimeoutInSeconds> एलिमेंट

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

<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>

डिफ़ॉल्ट:

30

मौजूदगी:

 वैकल्पिक

टाइप:

पूर्णांक

<CacheResource> एलिमेंट

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

<CacheResource>cache_to_use</CacheResource>

डिफ़ॉल्ट:

लागू नहीं

मौजूदगी:

 वैकल्पिक

टाइप:

स्ट्रिंग

कैश मेमोरी को कॉन्फ़िगर करने के बारे में ज़्यादा जानने के लिए, एनवायरमेंट कैश मेमोरी बनाना और उसमें बदलाव करना लेख पढ़ें.

<CacheKey>/<KeyFragment> एलिमेंट

यह ऐसी वैल्यू तय करता है जिसे कैश मेमोरी की कुंजी में शामिल किया जाना चाहिए. इससे कैश मेमोरी में सेव की गई प्रतिक्रियाओं से मेल खाने वाले अनुरोधों के लिए नेमस्पेस बनता है.

<KeyFragment ref="variable_name"/>
<KeyFragment>literal_string</KeyFragment>

डिफ़ॉल्ट:

लागू नहीं

मौजूदगी:

 वैकल्पिक

टाइप:

लागू नहीं

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

<KeyFragment>apiAccessToken</KeyFragment>
<KeyFragment ref="request.queryparam.client_id" />

<Prefix> और <Scope> के साथ <KeyFragment> एलिमेंट का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, कैश मेमोरी की कुंजियों का इस्तेमाल करना लेख पढ़ें.

विशेषताएं

एट्रिब्यूट टाइप डिफ़ॉल्ट ज़रूरी है ब्यौरा
ref स्ट्रिंग नहीं

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

<CacheKey>/<Prefix> एलिमेंट

यह कुकी, कैश मेमोरी की कुंजी के प्रीफ़िक्स के तौर पर इस्तेमाल की जाने वाली वैल्यू के बारे में बताती है.

<Prefix>prefix_string</Prefix>

डिफ़ॉल्ट:

लागू नहीं

मौजूदगी:

 वैकल्पिक

टाइप:

स्ट्रिंग

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

<CacheKey> और <Scope> के साथ <Prefix> एलिमेंट का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, कैश मेमोरी की कुंजियों का इस्तेमाल करना लेख पढ़ें.

<ExcludeErrorResponse> एलिमेंट

फ़िलहाल, डिफ़ॉल्ट रूप से यह नीति, किसी भी संभावित स्टेटस कोड के साथ एचटीटीपी रिस्पॉन्स को कैश मेमोरी में सेव करती है. इसका मतलब है कि सफलता और गड़बड़ी, दोनों तरह के जवाबों को कैश मेमोरी में सेव किया जाता है. उदाहरण के लिए, 2xx और 3xx, दोनों स्टेटस कोड वाले जवाब डिफ़ॉल्ट रूप से कैश मेमोरी में सेव किए जाते हैं.

अगर आपको एचटीटीपी गड़बड़ी के स्टेटस कोड के साथ टारगेट रिस्पॉन्स को कैश मेमोरी में सेव नहीं करना है, तो इस एलिमेंट को true पर सेट करें. अगर यह एलिमेंट सही है, तो 200 से 205 तक के स्टेटस कोड वाले रिस्पॉन्स को ही कैश मेमोरी में सेव किया जाएगा. ये ऐसे एचटीटीपी स्टेटस कोड हैं जिन्हें Edge, "सक्सेस" कोड के तौर पर मानता है. इस सेटिंग को बदला नहीं जा सकता.

रिस्पॉन्स कैश मेमोरी के पैटर्न के बारे में जानने के लिए, यह कम्यूनिटी पोस्ट पढ़ें. इसमें बताया गया है कि यह एलिमेंट किस तरह से काम आता है.

ध्यान दें: आने वाले समय में रिलीज़ होने वाले वर्शन में, इस एलिमेंट की डिफ़ॉल्ट सेटिंग बदलकर सही हो जाएगी. हालांकि, यह कब रिलीज़ होगा, यह अभी तय नहीं किया गया है. ज़्यादा जानकारी के लिए, Apigee के रिलीज़ नोट देखें.

<ExcludeErrorResponse>true</ExcludeErrorResponse>

डिफ़ॉल्ट:

गलत

मौजूदगी:

 वैकल्पिक

टाइप:

बूलियन

<ExpirySettings> एलिमेंट

यह कुकी बताती है कि कैश मेमोरी की एंट्री कब खत्म होनी चाहिए. इसकी मौजूदगी में, <TimeoutInSeconds>, <TimeOfDay> और <ExpiryDate>, दोनों को बदल देता है.

<ExpirySettings>
  <TimeOfDay ref="time_variable">expiration_time</TimeOfDay>
  <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds>
  <ExpiryDate ref="date_variable">expiration_date</ExpiryDate>
</ExpirySettings>

डिफ़ॉल्ट:

लागू नहीं

मौजूदगी:

 ज़रूरी है

टाइप:

लागू नहीं

<ExpirySettings>/<ExpiryDate> एलिमेंट

इससे उस तारीख के बारे में पता चलता है जब कैश मेमोरी की एंट्री खत्म हो जानी चाहिए. mm-dd-yyyy फ़ॉर्म का इस्तेमाल करें. अगर यह मौजूद है, तो इस एलिमेंट का सिबलिंग, <TimeoutInSeconds>, <ExpiryDate> को बदल देता है.

<ExpirySettings>
    <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate>
</ExpirySettings>

डिफ़ॉल्ट:

लागू नहीं

मौजूदगी:

 वैकल्पिक

टाइप:

स्ट्रिंग

विशेषताएं

<ExpiryDate ref="" />
एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी टाइप
ref

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

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

<ExpirySettings>/<TimeOfDay> एलिमेंट

दिन का वह समय जब कैश मेमोरी की एंट्री खत्म हो जानी चाहिए. hh:mm:ss फ़ॉर्म का इस्तेमाल करें . अगर यह मौजूद है, तो इस एलिमेंट का सिबलिंग, <TimeoutInSeconds>, <TimeOfDay> को बदल देता है.

दिन का समय HH:mm:ss फ़ॉर्मैट में डालें. यहां HH का मतलब 24 घंटे की घड़ी के हिसाब से घंटे से है. उदाहरण के लिए, दोपहर 2:30 बजे के लिए 14:30:00.

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

<ExpirySettings>
    <TimeOfDay ref="time_variable">expiration_time</TimeOfDay>
</ExpirySettings>

डिफ़ॉल्ट:

 लागू नहीं

मौजूदगी:

 वैकल्पिक

टाइप:

स्ट्रिंग

विशेषताएं

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

<ExpirySettings>/<TimeoutInSec> एलिमेंट

यह वह समय है जिसके बाद कैश मेमोरी में मौजूद एंट्री की समयसीमा खत्म हो जाती है.

<ExpirySettings>/<TimeoutInSeconds> एलिमेंट

यह वह समय है जिसके बाद कैश मेमोरी में मौजूद एंट्री की समयसीमा खत्म हो जाती है. यह एलिमेंट मौजूद होने पर, अपने साथ मौजूद एलिमेंट <TimeOfDay> और <ExpiryDate> को बदल देता है.

<ExpirySettings>
    <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds>
</ExpirySettings>

ध्यान दें: अगर रेफ़ को duration_variable से वैल्यू नहीं मिलती है, तो इस्तेमाल के लिए डिफ़ॉल्ट टाइमआउट वैल्यू दें.

डिफ़ॉल्ट:

लागू नहीं

मौजूदगी:

 वैकल्पिक

टाइप:

स्ट्रिंग

विशेषताएं

एट्रिब्यूट ब्यौरा डिफ़ॉल्ट मौजूदगी टाइप
ref टाइम आउट की वैल्यू वाला वैरिएबल.
लागू नहीं
वैकल्पिक स्ट्रिंग

<Scope> एलिमेंट

इस इन्यूमरेशन का इस्तेमाल, कैश मेमोरी की कुंजी के लिए प्रीफ़िक्स बनाने के लिए किया जाता है. ऐसा तब होता है, जब <CacheKey> एलिमेंट में <Prefix> एलिमेंट नहीं दिया जाता है.

<Scope>scope_enumeration</Scope>

डिफ़ॉल्ट:

"एक्सक्लूसिव"

मौजूदगी:

 वैकल्पिक

टाइप:

स्ट्रिंग

<Scope> सेटिंग से, कैश मेमोरी की ऐसी कुंजी तय होती है जिसे <Scope> वैल्यू के हिसाब से पहले जोड़ा जाता है. उदाहरण के लिए, जब स्कोप को Exclusive पर सेट किया जाता है, तो कैश मेमोरी की कुंजी इस फ़ॉर्म में होती है: orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [ serializedCacheKey ].

अगर <CacheKey> में <Prefix> एलिमेंट मौजूद है, तो यह <Scope> एलिमेंट की वैल्यू को बदल देता है. मान्य वैल्यू में यहां दी गई गिनती शामिल है.

<CacheKey> और <Prefix> के साथ <Scope> एलिमेंट का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, कैश मेमोरी की कुंजियों का इस्तेमाल करना लेख पढ़ें.

स्वीकार की जा सकने वाली वैल्यू

स्कोप की वैल्यू ब्यौरा
Global

कैश कुंजी, एनवायरमेंट में डिप्लॉय की गई सभी एपीआई प्रॉक्सी के साथ शेयर की जाती है. कैश मेमोरी की कुंजी को orgName __ envName __ के तौर पर जोड़ा जाता है.

अगर आपने <KeyFragment> apiAccessToken और <Global> स्कोप के साथ <CacheKey> एंट्री तय की है, तो हर एंट्री को orgName__envName__apiAccessToken के तौर पर सेव किया जाता है. इसके बाद, ऐक्सेस टोकन की क्रम से लगाई गई वैल्यू सेव की जाती है. 'apifactory' नाम के संगठन में 'test' नाम के एनवायरमेंट में डिप्लॉय की गई एपीआई प्रॉक्सी के लिए, ऐक्सेस टोकन को इस कैश मेमोरी की कुंजी के तहत सेव किया जाएगा: apifactory__test__apiAccessToken.
Application

एपीआई प्रॉक्सी के नाम का इस्तेमाल प्रीफ़िक्स के तौर पर किया जाता है.

कैश कुंजी को orgName__envName__apiProxyName के फ़ॉर्मैट में जोड़ा जाता है.
Proxy

ProxyEndpoint कॉन्फ़िगरेशन का इस्तेमाल प्रीफ़िक्स के तौर पर किया जाता है.

कैश कुंजी को इस फ़ॉर्म में पहले से जोड़ दिया जाता है: orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName .
Target

TargetEndpoint कॉन्फ़िगरेशन का इस्तेमाल प्रीफ़िक्स के तौर पर किया जाता है.

कैश कुंजी, इस फ़ॉर्म में पहले से मौजूद होती है orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName .
Exclusive

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

प्रीफ़िक्स इन दोनों में से किसी एक फ़ॉर्म में होता है:

  • अगर नीति को ProxyEndpoint फ़्लो से अटैच किया जाता है, तो प्रीफ़िक्स ApiProxyName_ProxyEndpointName फ़ॉर्म में होता है.
  • अगर नीति को TargetEndpoint पर अटैच किया जाता है, तो प्रीफ़िक्स इस फ़ॉर्म में होता है: ApiProxyName_TargetName.

फ़ॉर्म में पहले से मौजूद कैश मेमोरी की कुंजी orgName__envName__apiProxyName__deployedRevisionNumber__proxyNameITargetName

उदाहरण के लिए, पूरी स्ट्रिंग कुछ ऐसी दिख सकती है:

apifactory__test__weatherapi__16__default__apiAccessToken
.

<SkipCacheLookup> एलिमेंट

यह एक ऐसा एक्सप्रेशन तय करता है जो रनटाइम में सही होने पर, यह तय करता है कि कैश मेमोरी में मौजूद डेटा को नहीं देखना है और कैश मेमोरी को रीफ़्रेश करना है. SkipCacheLookup के इस्तेमाल के बारे में जानने के लिए, यह वीडियो भी देखें.

<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>

डिफ़ॉल्ट:

लागू नहीं

मौजूदगी:

 वैकल्पिक

टाइप:

स्ट्रिंग

यहां दिए गए उदाहरण में, अगर आने वाले हेडर में bypass-cache वैरिएबल को true पर सेट किया जाता है, तो कैश मेमोरी में मौजूद डेटा को नहीं देखा जाता और कैश मेमोरी को रीफ़्रेश कर दिया जाता है.

<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>

<SkipCachePopulation> एलिमेंट

यह एक ऐसा एक्सप्रेशन तय करता है जो रनटाइम में सही होने पर, यह तय करता है कि कैश मेमोरी में लिखने की प्रोसेस को स्किप किया जाना चाहिए. SkipCachePopulation के इस्तेमाल के बारे में जानने के लिए, यह वीडियो भी देखें.

<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>

डिफ़ॉल्ट:

लागू नहीं

मौजूदगी:

 वैकल्पिक

टाइप:

स्ट्रिंग

उदाहरण के लिए, अगर रिस्पॉन्स का स्टेटस कोड 400 या इससे ज़्यादा है, तो नीचे दिया गया कोड कैश मेमोरी में लिखने की प्रोसेस को छोड़ देगा:

<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>

<UseAcceptHeader> एलिमेंट

इसे true पर सेट करें, ताकि रिस्पॉन्स कैश मेमोरी की एंट्री के कैश मेमोरी कुंजी में, रिस्पॉन्स के Accept हेडर से मिली वैल्यू जोड़ी जा सकें.

कैश मेमोरी की कुंजी का हिसाब लगाते समय, Edge Accept, Accept-Encoding, Accept-Language, और Accept-Charset अनुरोध हेडर का इस्तेमाल करता है. इस तरीके से, क्लाइंट को ऐसा मीडिया टाइप नहीं मिलता है जिसके लिए उसने अनुरोध नहीं किया है.

उदाहरण के लिए, मान लें कि एक ही यूआरएल से दो अनुरोध आते हैं. पहले अनुरोध में gzip को स्वीकार किया जाता है, जबकि दूसरे अनुरोध में gzip को स्वीकार नहीं किया जाता. पहले अनुरोध को कैश मेमोरी में सेव किया जाएगा. साथ ही, कैश मेमोरी में सेव की गई एंट्री, (शायद) gzip फ़ॉर्मैट में सेव की गई प्रतिक्रिया होगी. दूसरे अनुरोध में, कैश मेमोरी में सेव की गई वैल्यू को पढ़ा जाएगा. इसके बाद, यह gzip फ़ॉर्मैट में सेव की गई एंट्री को ऐसे क्लाइंट को भेज सकता है जो gzip फ़ॉर्मैट को नहीं पढ़ सकता.

ज़्यादा जानकारी के लिए, कैश मेमोरी की कुंजी कॉन्फ़िगर करना लेख पढ़ें.

<UseAcceptHeader>false</UseAcceptHeader>

डिफ़ॉल्ट:

गलत

मौजूदगी:

 वैकल्पिक

टाइप:

बूलियन

<UseResponseCacheHeaders> एलिमेंट

इसे true पर सेट करें, ताकि कैश मेमोरी में मौजूद जवाब का "लाइव होने में लगने वाला समय" (टीटीएल) सेट करते समय, एचटीटीपी रिस्पॉन्स हेडर को ध्यान में रखा जा सके. ऐसा होने पर, Edge इन रिस्पॉन्स हेडर की वैल्यू पर विचार करता है. साथ ही, इन वैल्यू की तुलना <ExpirySettings> की ओर से सेट की गई वैल्यू से करता है. ऐसा तब होता है, जब टाइम टू लिव सेट किया जाता है:

  • Cache-Control s-maxage
  • Cache-Control max-age
  • Expires

ज़्यादा जानकारी के लिए, कैश मेमोरी में सेव की गई एंट्री के खत्म होने का समय सेट करना लेख पढ़ें.

<UseResponseCacheHeaders>false</UseResponseCacheHeaders>

डिफ़ॉल्ट:

गलत

मौजूदगी:

 वैकल्पिक

टाइप:

बूलियन

इस्तेमाल की जानकारी

कैश किए गए हर ऑब्जेक्ट का साइज़ 256 केबी से ज़्यादा नहीं होना चाहिए. (Edge, कैश मेमोरी को कैसे प्रोसेस करता है, इस बारे में ज़्यादा जानने के लिए कैश मेमोरी की इंटरनल प्रोसेस देखें.)

ResponseCache नीति में कॉन्फ़िगरेशन के ज़रिए, Edge को यह निर्देश दिया जा सकता है कि वह कैश मेमोरी की एंट्री की समयसीमा खत्म होने और कैश मेमोरी की कुंजियों को सेट करने के लिए, एचटीटीपी रिस्पॉन्स हेडर शामिल करे. इस सेक्शन में बताया गया है कि हेडर के साथ नीति का इस्तेमाल करके, कैश मेमोरी की समयसीमा खत्म होने और कैश मेमोरी की कुंजियों को कैसे मैनेज किया जा सकता है.

Edge, ResponseCache नीति के साथ रिस्पॉन्स हेडर को कैसे मैनेज करता है, इस बारे में ज़्यादा जानने के लिए एचटीटीपी रिस्पॉन्स हेडर के लिए सहायता लेख पढ़ें.

कैश मेमोरी में मौजूद एंट्री की समयसीमा खत्म होने की तारीख सेट करना

कैश मेमोरी में डेटा सेव करने की नीति की तरह ही, <ExpirySettings> एलिमेंट का इस्तेमाल करके, रिस्पॉन्स कैश मेमोरी में सेव किए गए डेटा के खत्म होने की अवधि (टाइम टू लिव) सेट की जा सकती है. ResponseCache नीति में, Edge को रिस्पॉन्स हेडर पर भी विचार करने के लिए कहा जा सकता है.

जवाब के हेडर का इस्तेमाल करने के लिए, <UseResponseCacheHeaders> एलिमेंट की वैल्यू को सही पर सेट करें. इस सेटिंग की वजह से Edge, जवाब के हेडर पर विचार करता है. इसके बाद, उनकी तुलना <ExpirySettings> की ओर से सेट की गई वैल्यू से करता है. इसके बाद, दोनों में से सबसे कम वैल्यू का इस्तेमाल करता है. जवाब के हेडर पर विचार करते समय, Edge यहां दी गई जानकारी के मुताबिक उपलब्ध वैल्यू चुनता है:

उदाहरण के लिए, मान लें कि किसी रिस्पॉन्स को इन वैल्यू के साथ कैश मेमोरी में सेव किया गया है:

  • Cache-Control s-maxage एट्रिब्यूट की कोई वैल्यू मौजूद नहीं है
  • Cache-Control max-age की वैल्यू 300
  • तीन दिन बाद की Expires तारीख
  • <ExpirySettings> TimeoutInSeconds की वैल्यू 600.

इस मामले में, टीटीएल के लिए Cache-Control max-age वैल्यू का इस्तेमाल किया जाएगा, क्योंकि यह <ExpirySettings> वैल्यू से कम है. साथ ही, Cache-Control s-maxage वैल्यू मौजूद नहीं है, जो max-age से ज़्यादा प्राथमिकता लेती है.

कैश मेमोरी की कुंजी को कॉन्फ़िगर करना

Populate Cache policy जैसी सामान्य कैश मेमोरी की नीतियों की तरह ही, ResponseCache के साथ <CacheKey> और <Scope> एलिमेंट का इस्तेमाल किया जाता है. इनका इस्तेमाल, कैश मेमोरी की एंट्री के लिए कैश मेमोरी की कुंजी बनाने की सुविधा को कॉन्फ़िगर करने के लिए किया जाता है. ResponseCache की मदद से, कैश मेमोरी की कुंजियों को ज़्यादा काम का बनाया जा सकता है. इसके लिए, रिस्पॉन्स के Accept हेडर को कुंजी की वैल्यू में जोड़ा जाता है.

कैश मेमोरी की कुंजियां कॉन्फ़िगर करने के बारे में सामान्य जानकारी के लिए, कैश मेमोरी की कुंजियों का इस्तेमाल करना लेख पढ़ें. Accept हेडर इस्तेमाल करने के बारे में जानकारी के लिए, <UseAcceptHeader> देखें.

कैश मेमोरी को एन्क्रिप्ट (सुरक्षित) करने के बारे में जानकारी

सार्वजनिक क्लाउड के लिए Edge: कैश मेमोरी को सिर्फ़ इन संगठनों में एन्क्रिप्ट (सुरक्षित) किया जाता है: पीसीआई- और HIPAA-अनुपालक संगठन. इन संगठनों के लिए एन्क्रिप्शन, संगठन के लिए सेवा चालू करने के दौरान कॉन्फ़िगर किया जाता है.

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

ResponseCache नीति लागू होने पर, पहले से तय किए गए ये फ़्लो वैरिएबल भर जाते हैं. फ़्लो वैरिएबल के बारे में ज़्यादा जानने के लिए, वैरिएबल का रेफ़रंस देखें.

वैरिएबल टाइप अनुमति ब्यौरा
responsecache.{policy_name}.cachename स्ट्रिंग रीड-ओनली नीति में इस्तेमाल की गई कैश मेमोरी दिखाता है
responsecache.{policy_name}.cachekey स्ट्रिंग रीड-ओनली इस्तेमाल की गई कुंजी दिखाता है
responsecache.{policy_name}.cachehit बूलियन रीड-ओनली नीति लागू होने पर, वैल्यू 'सही है' पर सेट होती है
responsecache.{policy_name}.invalidentry बूलियन रीड-ओनली अगर कैश मेमोरी की एंट्री मान्य नहीं है, तो वैल्यू 'सही' के तौर पर सेट होगी

गड़बड़ी के कोड

This section describes the error messages and flow variables that are set when this policy triggers an error. This information is important to know if you are developing fault rules for a proxy. To learn more, see What you need to know about policy errors and Handling faults.

Error code prefix

N/A

Runtime errors

This policy does not throw any runtime errors.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Error name Cause Fix
InvalidTimeout If the <CacheLookupTimeoutInSeconds> element of the ResponseCache policy is set to a negative number, then the deployment of the API proxy fails.
InvalidCacheResourceReference This error occurs if the <CacheResource> element in a ResponseCache policy is set to a name that does not exist in the environment where the API proxy is being deployed.
ResponseCacheStepAttachmentNotAllowedReq This error occurs if the same ResponseCache policy is attached to multiple request paths within any flows of an API proxy.
ResponseCacheStepAttachmentNotAllowedResp This error occurs if the same ResponseCache policy is attached to multiple response paths within any flows of an API proxy.
InvalidMessagePatternForErrorCode This error occurs if either the <SkipCacheLookup> or the <SkipCachePopulation> element in a ResponseCache policy contains an invalid condition.
CacheNotFound This error occurs if the specific cache mentioned in the error message has not been created on a specific Message Processor component.

Fault variables

N/A

Example error response

N/A

स्कीमा

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