Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी
यह किसी बैकएंड संसाधन से मिलने वाले डेटा को कैश मेमोरी में सेव करता है. इससे संसाधन को मिलने वाले अनुरोधों की संख्या कम हो जाती है. ऐप्लिकेशन, एक ही यूआरआई के लिए अनुरोध करते हैं. इसलिए, इस नीति का इस्तेमाल करके उन अनुरोधों को बैकएंड सर्वर पर भेजने के बजाय, कैश मेमोरी में सेव किए गए रिस्पॉन्स वापस किए जा सकते हैं. Responseकैश नीति से, आपके एपीआई की परफ़ॉर्मेंस बेहतर हो सकती है. इसके लिए, इंतज़ार का समय और नेटवर्क ट्रैफ़िक को कम किया जाता है.
आपका एपीआई जिस बैकएंड डेटा का इस्तेमाल करता है उसे समय-समय पर अपडेट करने पर, आपको Response cache सबसे ज़्यादा काम का लग सकता है. उदाहरण के लिए, मान लें कि आपके पास एक ऐसा एपीआई है जो सिर्फ़ हर दस मिनट में रीफ़्रेश होने वाली, मौसम की रिपोर्ट का डेटा दिखाता है. रीफ़्रेश के बीच कैश मेमोरी में सेव किए गए रिस्पॉन्स दिखाने के लिए, Responsecache का इस्तेमाल करके, बैकएंड तक पहुंचने वाले अनुरोधों की संख्या कम की जा सकती है. इससे, नेटवर्क के इधर-उधर जाने की संख्या भी कम हो जाती है.
सामान्य मकसद के लिए, कुछ समय के लिए कैश मेमोरी में सेव करना, कैश मेमोरी से जुड़ी नीति का इस्तेमाल करने के बारे में सोचें. इस नीति का इस्तेमाल लुकअप कैश नीति (कैश मेमोरी में सेव की गई एंट्री को पढ़ने के लिए) और कैश मेमोरी को अमान्य करने से जुड़ी नीति (एंट्री अमान्य करने के लिए) के साथ किया जाता है.
रिस्पॉन्स कैश से जुड़ी नीति के बारे में जानने के लिए, यह वीडियो देखें.
सैंपल
10 मिनट की कैश मेमोरी
इस सैंपल में, कैश मेमोरी में सेव किए गए जवाबों को 10 मिनट तक सेव रखने का तरीका बताया गया है.
मान लें कि आपके पास इस यूआरएल पर एक एपीआई है:
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
आप क्वेरी पैरामीटर w
का इस्तेमाल कैश कुंजी के तौर पर कर रहे हैं. अनुरोध मिलने पर, Apigee Edge, क्वेरी पैरामीटर w
की वैल्यू की जांच करता है. अगर कैश में कोई मान्य
रिस्पॉन्स मौजूद है, जिसकी समयसीमा खत्म नहीं हुई है, तो कैश मेमोरी में सेव किया गया रिस्पॉन्स मैसेज,
अनुरोध करने वाले क्लाइंट को भेज दिया जाता है.
अब मान लें कि आपकी Response cache नीति इस तरह से कॉन्फ़िगर की गई हो.
<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
कैश लुकअप छोड़ें
यहां दिए गए उदाहरण में, कैश लुकअप को स्किप करने और कैश मेमोरी को रीफ़्रेश करने का तरीका बताया गया है. स्किप कैश लुकअप के इस्तेमाल के बारे में जानने के लिए यह वीडियो भी देखें.
वैकल्पिक स्किप कैश लुकअप स्थिति (अगर कॉन्फ़िगर की गई है) का आकलन अनुरोध के पाथ में किया जाता है. अगर स्थिति 'सही' के तौर पर मिलती है, तो कैश लुक अप की प्रोसेस को छोड़ दिया जाता है और कैश मेमोरी को रीफ़्रेश कर दिया जाता है.
कंडिशनल कैश मेमोरी को रीफ़्रेश करने का एक सामान्य इस्तेमाल एक ऐसी शर्त है जो खास एचटीटीपी हेडर के बारे में बताती है. इसकी वजह से शर्त सही के तौर पर मिलती है. स्क्रिप्ट किए गए किसी क्लाइंट ऐप्लिकेशन को समय-समय पर सही एचटीटीपी हेडर के साथ अनुरोध सबमिट करने के लिए कॉन्फ़िगर किया जा सकता है. इसकी वजह से, रिस्पॉन्स कैश मेमोरी रीफ़्रेश हो रही है.
उदाहरण के लिए, मान लें कि नीचे दिए गए यूआरएल पर किसी एपीआई को कॉल किया जाए:
'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"
अब उस प्रॉक्सी पर कॉन्फ़िगर की गई नीचे दी गई Response आकलन नीति देखें. ध्यान दें कि बायपास-कैश की स्थिति को 'सही' पर सेट किया गया है.
<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 |
नीति का अंदरूनी नाम. इसके अलावा, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में नीति को आम भाषा में अलग नाम से लेबल करने के लिए, |
लागू नहीं | ज़रूरी है |
continueOnError |
इस नीति को किसी नीति के काम न करने पर भी फ़्लो एक्ज़ीक्यूट करने की प्रोसेस को जारी रखने के लिए, |
false | ज़रूरी नहीं |
enabled |
नीति लागू करने के लिए, नीति को बंद करने के लिए, |
सही | ज़रूरी नहीं |
async |
यह एट्रिब्यूट अब काम नहीं करता. |
false | बहिष्कृत |
<DisplayName> एलिमेंट
मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में, आम भाषा के अलग नाम से नीति को लेबल करने के लिए, name
एट्रिब्यूट का इस्तेमाल करें.
<DisplayName>Policy Display Name</DisplayName>
डिफ़ॉल्ट |
लागू नहीं अगर इस एलिमेंट को छोड़ दिया जाता है, तो नीति के |
---|---|
मौजूदगी | ज़रूरी नहीं |
Type | String |
<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>
<CacheKey>
एलिमेंट का इस्तेमाल <Prefix>
और <Scope>
के साथ किया जाता है. ज़्यादा जानकारी के लिए, कैश कुंजी के साथ काम करना लेख पढ़ें.
< cachelookupTimeoutInSeconds> एलिमेंट
यह नीति सेकंड की वह संख्या तय करती है जिसके बाद, कैश मेमोरी की जांच नहीं होने पर उसे कैश मेमोरी में सेव नहीं माना जाएगा. अगर ऐसा होता है, तो फ़्लो, कैश मेमोरी में सेव किए गए डेटा को हटाने की प्रोसेस के पाथ पर फिर से शुरू हो जाता है.
<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>
डिफ़ॉल्ट: |
30 |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
पूर्णांक |
<cacheResource> एलिमेंट
इस नीति की मदद से, यह तय किया जाता है कि मैसेज किस कैश मेमोरी में सेव किए जाएं. शामिल की गई कैश मेमोरी का इस्तेमाल करने के लिए, इस एलिमेंट का इस्तेमाल न करें. अगर आपको कैश मेमोरी में मौजूद एंट्री को एडमिन के तौर पर हटाना है, तो आपको नाम के साथ cacheResource तय करना होगा. इस बारे में ज़्यादा जानकारी के लिए, कैश मेमोरी देखें.
<CacheResource>cache_to_use</CacheResource>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
स्ट्रिंग |
कैश मेमोरी कॉन्फ़िगर करने के बारे में ज़्यादा जानने के लिए, एनवायरमेंट कैश बनाना और उसमें बदलाव करना लेख पढ़ें.
<cacheKey>/<Keyफ़्रैगमेंट> एलिमेंट
इस नीति से वह वैल्यू तय की जाती है जिसे कैश कुंजी में शामिल किया जाना चाहिए. इससे कैश मेमोरी में सेव किए गए रिस्पॉन्स से मेल खाने वाले अनुरोधों के लिए एक नेमस्पेस बनाया जाता है.
<KeyFragment ref="variable_name"/> <KeyFragment>literal_string</KeyFragment>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
लागू नहीं |
यह कोई कुंजी (आपकी तरफ़ से दिया गया स्टैटिक नाम) या कोई वैल्यू (किसी वैरिएबल का रेफ़रंस देकर सेट की गई डाइनैमिक एंट्री) हो सकती है. कैश कुंजी बनाने के लिए, दिए गए सभी फ़्रैगमेंट (और प्रीफ़िक्स) को एक साथ जोड़ा जाता है.
<KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" />
<KeyFragment>
एलिमेंट का इस्तेमाल <Prefix>
और <Scope>
के साथ किया जाता है. ज़्यादा जानकारी के लिए, कैश कुंजी के साथ काम करना लेख पढ़ें.
एट्रिब्यूट
एट्रिब्यूट | टाइप | डिफ़ॉल्ट | ज़रूरी है | ब्यौरा |
---|---|---|---|---|
संदर्भ | स्ट्रिंग | नहीं |
वह वैरिएबल जिससे वैल्यू पाना है. अगर इस एलिमेंट में लिटरल वैल्यू है, तो इसका इस्तेमाल नहीं किया जाना चाहिए. |
<cacheKey>/<प्रीफ़िक्स> एलिमेंट
इससे पता चलता है कि वैल्यू को कैश कुंजी प्रीफ़िक्स के तौर पर इस्तेमाल करना है.
<Prefix>prefix_string</Prefix>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
स्ट्रिंग |
जब आपको <Scope>
की गिनती के बजाय खुद की वैल्यू देनी हो, तो <Scope>
के बजाय इस वैल्यू का इस्तेमाल करें. अगर तय किया गया हो, तो
<Prefix>
, कैश मेमोरी में लिखी गई एंट्री के लिए, कैश कुंजी की वैल्यू से पहले जोड़ देता है. <Prefix>
एलिमेंट की वैल्यू, <Scope>
एलिमेंट की वैल्यू को बदल देती है.
<Prefix>
एलिमेंट का इस्तेमाल <CacheKey>
और <Scope>
के साथ किया जाता है. ज़्यादा जानकारी के लिए, कैश कुंजी के साथ काम करना लेख पढ़ें.
<ExcludeErrorResponse> एलिमेंट
फ़िलहाल, यह नीति डिफ़ॉल्ट रूप से, एचटीटीपी रिस्पॉन्स को किसी भी संभावित स्टेटस कोड के साथ कैश मेमोरी में सेव करती है. इसका मतलब है कि कामयाबी और गड़बड़ी के रिस्पॉन्स, दोनों को कैश मेमोरी में सेव किया जाता है. उदाहरण के लिए, 2xx और 3xx स्टेटस कोड वाले जवाबों को डिफ़ॉल्ट रूप से कैश मेमोरी में सेव किया जाता है.
अगर आपको एचटीटीपी गड़बड़ी के स्टेटस कोड वाले टारगेट रिस्पॉन्स को कैश मेमोरी में सेव नहीं करना है, तो इस एलिमेंट को true
पर सेट करें. अगर एलिमेंट सही है, तो सिर्फ़ 200 से 205 के स्टेटस कोड वाले रिस्पॉन्स को कैश मेमोरी में सेव किया जाएगा. सिर्फ़ इन्हीं एचटीटीपी स्टेटस कोड को Edge है, जिन्हें "सक्सेस" कोड के तौर पर गिना जाता है. साथ ही, इस असोसिएशन को बदला नहीं जा सकता.
इस एलिमेंट से जुड़े रिस्पॉन्स कैश पैटर्न के बारे में ज़्यादा जानने के लिए, यह कम्यूनिटी पोस्ट देखें.
ध्यान दें: आने वाले समय की रिलीज़ में (तय किया जाना बाकी है), इस एलिमेंट की डिफ़ॉल्ट सेटिंग सही में बदल जाएगी. ज़्यादा जानकारी के लिए, Apigee के रिलीज़ नोट्स देखें.
<ExcludeErrorResponse>true</ExcludeErrorResponse>
डिफ़ॉल्ट: |
false |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
बूलियन |
<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="" />
एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी | टाइप |
---|---|---|---|---|
संदर्भ |
वह वैरिएबल जिससे वैल्यू पाना है. अगर इस एलिमेंट में लिटरल वैल्यू है, तो इसका इस्तेमाल नहीं किया जाना चाहिए. |
लागू नहीं | ज़रूरी नहीं | स्ट्रिंग |
<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>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
स्ट्रिंग |
एट्रिब्यूट
एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी | टाइप |
---|---|---|---|---|
संदर्भ | खत्म होने की अवधि की वैल्यू वाला वैरिएबल. | लागू नहीं | ज़रूरी नहीं | स्ट्रिंग |
<ExpirySettings>/<TimeoutInSec> एलिमेंट
सेकंड की वह संख्या जिसके बाद कैश एंट्री खत्म होनी चाहिए.
<ExpirySettings>/<TimeoutInSeconds> एलिमेंट
सेकंड की वह संख्या जिसके बाद कैश एंट्री खत्म होनी चाहिए. मौजूद होने पर, यह एलिमेंट
अपने सिबलिंग, <TimeOfDay>
, और <ExpiryDate>
को बदल देता है.
<ExpirySettings> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> </ExpirySettings>
ध्यान दें: अगर रेफ़रर को duration_variable
से कोई वैल्यू नहीं मिलती है, तो डिफ़ॉल्ट टाइम आउट वैल्यू दें.
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
स्ट्रिंग |
एट्रिब्यूट
एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी | टाइप |
---|---|---|---|---|
संदर्भ | टाइम आउट वैल्यू वाला वैरिएबल. |
लागू नहीं
|
ज़रूरी नहीं | स्ट्रिंग |
<Scope> एलिमेंट
जब <CacheKey>
एलिमेंट में <Prefix>
एलिमेंट नहीं दिया जाता है, तब कैश कुंजी के लिए प्रीफ़िक्स बनाने के लिए इस्तेमाल की जाने वाली गिनती.
<Scope>scope_enumeration</Scope>
डिफ़ॉल्ट: |
"खास" |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
स्ट्रिंग |
<Scope>
सेटिंग एक कैश कुंजी तय करती है, जिसे <Scope>
वैल्यू के हिसाब से
पहले जोड़ा जाता है. उदाहरण के लिए, जब
स्कोप Exclusive
पर सेट किया जाता है, तो कैश कुंजी इस तरह से दिखेगी:
orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [
orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ ].
अगर <CacheKey>
में <Prefix>
एलिमेंट मौजूद है, तो यह
<Scope>
एलिमेंट वैल्यू की जगह ले लेगा. मान्य वैल्यू में, नीचे दी गई सूचियां
शामिल हैं.
<Scope>
एलिमेंट का इस्तेमाल <CacheKey>
और <Prefix>
के साथ किया जाता है. ज़्यादा जानकारी के लिए, कैश कुंजी के साथ काम करना लेख पढ़ें.
स्वीकार की जा सकने वाली वैल्यू
स्कोप वैल्यू | ब्यौरा |
---|---|
Global |
कैश कुंजी, एनवायरमेंट में डिप्लॉय की गई सभी एपीआई प्रॉक्सी के साथ शेयर की जाती है. कैश कुंजी orgName __ envName __ के रूप में पहले जोड़ी जाती है. अगर आपने
|
Application |
एपीआई प्रॉक्सी के नाम का इस्तेमाल प्रीफ़िक्स के तौर पर किया जाता है. कैश कुंजी कुंजी को orgName__envName__apiProxyName के रूप में पहले जोड़ा जाता है. |
Proxy |
प्रॉक्सीEndpoint कॉन्फ़िगरेशन का इस्तेमाल प्रीफ़िक्स के तौर पर किया जाता है. कैश कुंजी कुंजी को orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName के रूप में पहले जोड़ा जाता है . |
Target |
TargetEndpoint कॉन्फ़िगरेशन का इस्तेमाल प्रीफ़िक्स के तौर पर किया जाता है. कैश कुंजी कुंजी को orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName फ़ॉर्म में पहले से जोड़ा जाता है . |
Exclusive |
डिफ़ॉल्ट. यह सबसे सटीक है. इसलिए, इससे किसी कैश मेमोरी में नेमस्पेस के टकराव का खतरा कम होता है. प्रीफ़िक्स इन दो फ़ॉर्म में से एक है:
कैश कुंजी, पहले से इस फ़ॉर्म में जोड़ी जाती है orgName__envName__apiProxyName__deployedRevisionNumber__proxyNameITargetName उदाहरण के लिए, पूरी स्ट्रिंग इस तरह दिख सकती है: apifactory__test__weatherapi__16__default__apiAccessToken. |
<स्किपकैशलुक> एलिमेंट
यह एक एक्सप्रेशन तय करता है. अगर इसका आकलन रनटाइम के समय सही के तौर पर होता है, तो यह तय करता है कि कैश लुकअप को स्किप करना चाहिए और कैश को रीफ़्रेश किया जाना चाहिए. स्किप कैश लुकअप के इस्तेमाल के बारे में जानने के लिए यह वीडियो भी देखें.
<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
स्ट्रिंग |
यहां दिए गए उदाहरण में से, अगर किसी इनकमिंग हेडर में बायपास-कैश वैरिएबल को 'सही' पर सेट किया गया है, तो कैश लुकअप को स्किप कर दिया जाता है. साथ ही, कैश मेमोरी को रीफ़्रेश कर दिया जाता है.
<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
<स्किपकैशपॉप्युलेशन> एलिमेंट
एक एक्सप्रेशन के बारे में बताता है. अगर यह रनटाइम के दौरान सही के तौर पर आकलन करता है, तो यह बताता है कि कैश मेमोरी में लिखने की सुविधा को छोड़ दिया जाना चाहिए. स्किप कैश पॉप्युलेशन के इस्तेमाल के बारे में जानने के लिए यह वीडियो भी देखें.
<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
स्ट्रिंग |
उदाहरण के लिए, रिस्पॉन्स स्टेटस कोड 400 या इससे ज़्यादा होने पर, ये कैश मेमोरी में सेव नहीं होंगे:
<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>
<Useस्वीकारHeader> एलिमेंट
रिस्पॉन्स कैश एंट्री की कैश कुंजी को रिस्पॉन्स स्वीकार करने वाले हेडर से
जोड़ी गई वैल्यू से जोड़ने के लिए, true
पर सेट करें.
कैश कुंजी को कैलकुलेट करते समय, Edge Accept
, Accept-Encoding
, Accept-Language
,
और Accept-Charset
अनुरोध के हेडर का इस्तेमाल करता है. इस तरीके से,
क्लाइंट को उस तरह का मीडिया नहीं दिखेगा जैसा उन्होंने नहीं पूछा है.
उदाहरण के लिए, मान लें कि अगर दो अनुरोध एक ही यूआरएल से आते हैं, जहां पहला अनुरोध gzip को स्वीकार करता है और दूसरा नहीं. पहला अनुरोध कैश मेमोरी में सेव किया जाएगा और कैश मेमोरी में सेव की गई एंट्री, gzip की गई रिस्पॉन्स होगी. दूसरा अनुरोध कैश मेमोरी में सेव की गई वैल्यू को पढ़ेगा और उसके बाद किसी ऐसे क्लाइंट को gzip की गई एंट्री दिखा सकता है जो gzip को पढ़ न सके.
ज़्यादा जानकारी के लिए कैश मेमोरी कुंजी कॉन्फ़िगर करना देखें.
<UseAcceptHeader>false</UseAcceptHeader>
डिफ़ॉल्ट: |
false |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
बूलियन |
<UseResponse cacheHeaders> एलिमेंट
इस वैल्यू को true
पर सेट करें, ताकि कैश मेमोरी में मौजूद रिस्पॉन्स के "टाइम टू लाइव" (टीटीएल) को सेट करते समय, एचटीटीपी रिस्पॉन्स हेडर पर गौर किया जा सके. जब यह सही होता है, तब एज इन रिस्पॉन्स हेडर की वैल्यू
को ध्यान में रखता है. साथ ही, लाइव होने का समय सेट करते समय,
इन रिस्पॉन्स हेडर की वैल्यू की तुलना <ExpirySettings>
से सेट की गई वैल्यू से की जाती है:
Cache-Control s-maxage
Cache-Control max-age
Expires
ज़्यादा जानकारी के लिए, कैश मेमोरी में डेटा सेव करने की समयसीमा सेट करना देखें.
<UseResponseCacheHeaders>false</UseResponseCacheHeaders>
डिफ़ॉल्ट: |
false |
मौजूदगी: |
ज़रूरी नहीं |
टाइप: |
बूलियन |
इस्तेमाल की जानकारी
हर कैश मेमोरी में सेव किए गए ऑब्जेक्ट का साइज़ 256 केबी से ज़्यादा नहीं होना चाहिए. (Edge कैश मेमोरी को कैसे प्रोसेस करता है, इस बारे में ज़्यादा जानकारी के लिए कैश इंटरनल लेख देखें.)
ResponseCash नीति के कॉन्फ़िगरेशन की मदद से, Edge में एचटीटीपी रिस्पॉन्स हेडर शामिल किए जा सकते हैं. ऐसा करके कैश एंट्री को खत्म करने की तारीख और कैश कुंजी सेट की जा सकती है. इस सेक्शन में बताया गया है कि कैश मेमोरी की समयसीमा खत्म होने की तारीख और कैश मेमोरी के बटन को मैनेज करने के लिए, हेडर के साथ इस नीति का इस्तेमाल किया जा सकता है.
Edge कैश मेमोरी की नीति के साथ रिस्पॉन्स हेडर को कैसे मैनेज करता है, इस बारे में ज़्यादा जानने के लिए एचटीटीपी रिस्पॉन्स हेडर के लिए सहायता लेख पढ़ें.
कैश एंट्री खत्म होने की तारीख सेट की जा रही है
कैश मेमोरी में डेटा भरने से जुड़ी नीति की तरह ही, <ExpirySettings>
एलिमेंट का इस्तेमाल करके रिस्पॉन्स कैश एंट्री की समयसीमा खत्म होने की तारीख (यह समय लाइव है) सेट की जा सकती है. ResponseCash की नीति में, Edge
रिस्पॉन्स हेडर मौजूद होने पर विचार करने का विकल्प भी दिया जा सकता है.
रिस्पॉन्स हेडर का इस्तेमाल करने के लिए, <UseResponseCacheHeaders>
एलिमेंट वैल्यू को
'सही' पर सेट करना होता है. इस सेटिंग की वजह से, Edge रिस्पॉन्स हेडर पर गौर करता है और उनकी तुलना <ExpirySettings>
की सेट की गई वैल्यू से करता है. इसके बाद, दोनों के बीच सबसे कम वैल्यू इस्तेमाल करता है. रिस्पॉन्स हेडर देखते समय, Edge यहां बताए गए तरीके से उपलब्ध वैल्यू चुनता है:
उदाहरण के लिए, मान लें कि किसी रिस्पॉन्स को इन वैल्यू के साथ कैश मेमोरी में सेव किया जाता है:
Cache-Control s-maxage
की कोई वैल्यू नहीं हैCache-Control max-age
की वैल्यू 300- तीन दिन में
Expires
तारीख <ExpirySettings>
TimeoutInSeconds
की वैल्यू 600 है.
इस मामले में, TTL (टीटीएल) के लिए Cache-Control
max-age
की वैल्यू का इस्तेमाल किया जाएगा, क्योंकि यह <ExpirySettings>
की वैल्यू से कम है. साथ ही, इसमें Cache-Control s-maxage
वैल्यू नहीं है (जिसकी प्राथमिकता max-age
से ज़्यादा है).
कैश मेमोरी कुंजी को कॉन्फ़िगर करना
कैश मेमोरी से जुड़ी नीति को पॉप्युलेट करने से जुड़ी नीति जैसी सामान्य ज़रूरतों के लिए बनाई गई कैश नीतियों के तरह, आप
Response कैश के साथ <CacheKey>
और <Scope>
एलिमेंट का इस्तेमाल करके,
कैश एंट्री के लिए कैश कुंजी बनाने की सुविधा को कॉन्फ़िगर करते हैं. Response cache की मदद से कैश कुंजियों
को ज़्यादा काम का बनाया जा सकता है.
इसके लिए, मुख्य वैल्यू में रिस्पॉन्स स्वीकार करने के हेडर जोड़कर, ऐसा किया जा सकता है.
कैश कुंजियों को कॉन्फ़िगर करने के बारे में सामान्य जानकारी के लिए, कैश कुंजी के साथ काम करना देखें. 'स्वीकार करें' हेडर का इस्तेमाल करने के बारे में जानकारी पाने के लिए, <UseAcceptHeader>
देखें.
कैश मेमोरी एन्क्रिप्ट (सुरक्षित) करने की सुविधा के बारे में जानकारी
Edge for Public Cloud: कैश मेमोरी को सिर्फ़ पीसीआई और हिपा की सुविधा वाले संगठनों में एन्क्रिप्ट (सुरक्षित) किया जाता है. उन संगठनों के लिए एन्क्रिप्शन, संगठन प्रावधान के दौरान कॉन्फ़िगर किया जाता है.
फ़्लो वैरिएबल
ResponseCash नीति के लागू होने पर, पहले से तय किए गए फ़्लो के इन वैरिएबल की जानकारी अपने-आप भर जाती है. फ़्लो वैरिएबल के बारे में ज़्यादा जानकारी के लिए, वैरिएबल रेफ़रंस देखें.
वैरिएबल | टाइप | अनुमति | ब्यौरा |
---|---|---|---|
responsecache.{policy_name}.cachename |
स्ट्रिंग | रीड-ओनली | नीति में इस्तेमाल की गई कैश मेमोरी दिखाता है |
responsecache.{policy_name}.cachekey |
स्ट्रिंग | रीड-ओनली | इस्तेमाल की गई कुंजी दिखाता है |
responsecache.{policy_name}.cachehit |
बूलियन | रीड-ओनली | नीति का पालन करने पर, वैल्यू 'सही' होगी |
responsecache.{policy_name}.invalidentry |
बूलियन | रीड-ओनली | अगर कैश एंट्री मान्य नहीं है, तो वैल्यू 'सही' होगी |
गड़बड़ी कोड
इस सेक्शन में गड़बड़ी के मैसेज और फ़्लो वैरिएबल के बारे में बताया गया है. ये वैरिएबल तब सेट किए जाते हैं, जब इस नीति के तहत कोई गड़बड़ी ट्रिगर होती है. यह जानकारी जानना ज़रूरी है कि क्या प्रॉक्सी के लिए गड़बड़ी के नियम बनाए जा रहे हैं. ज़्यादा जानने के लिए, नीति से जुड़ी गड़बड़ियों के बारे में आपके लिए ज़रूरी जानकारी और गड़बड़ियों को ठीक करने के तरीके देखें.
गड़बड़ी कोड प्रीफ़िक्स
लागू नहीं
रनटाइम से जुड़ी गड़बड़ियां
इस नीति के तहत रनटाइम में कोई गड़बड़ी नहीं होती है.
डिप्लॉयमेंट से जुड़ी गड़बड़ियां
ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाले किसी प्रॉक्सी को डिप्लॉय किया जाता है.
गड़बड़ी का नाम | वजह | समाधान |
---|---|---|
InvalidTimeout |
अगर
Responseकैश नीति के <CacheLookupTimeoutInSeconds> एलिमेंट को नेगेटिव नंबर पर सेट किया जाता है,
तो एपीआई प्रॉक्सी को डिप्लॉय नहीं किया जा सकता. |
build |
InvalidCacheResourceReference |
यह गड़बड़ी तब होती है, जब ResponseCache नीति में <CacheResource> एलिमेंट को किसी ऐसे नाम पर सेट किया गया हो जो उस एनवायरमेंट में मौजूद नहीं है जहां एपीआई प्रॉक्सी को डिप्लॉय किया जा रहा है. |
build |
ResponseCacheStepAttachmentNotAllowedReq |
यह गड़बड़ी तब होती है, जब एपीआई प्रॉक्सी के किसी भी फ़्लो में, Responseये से जुड़ी एक ही नीति को कई अनुरोध पाथ से जोड़ा जाता है. | build |
ResponseCacheStepAttachmentNotAllowedResp |
यह गड़बड़ी तब होती है, जब एक ही Response cache नीति को एपीआई प्रॉक्सी के किसी भी फ़्लो में, कई रिस्पॉन्स पाथ से जोड़ा जाता है. | build |
InvalidMessagePatternForErrorCode |
यह गड़बड़ी तब दिखती है, जब Responsecache नीति के <SkipCacheLookup> या <SkipCachePopulation> एलिमेंट में अमान्य शर्त मौजूद हो. |
build |
CacheNotFound |
यह गड़बड़ी तब होती है, जब गड़बड़ी के मैसेज में बताए गए कैश को किसी खास Message प्रोसेसर कॉम्पोनेंट पर न बनाया गया हो. | build |
गड़बड़ी वाले वैरिएबल
लागू नहीं
गड़बड़ी के जवाब का उदाहरण
लागू नहीं
स्कीमा
हर तरह की नीति को एक्सएमएल स्कीमा (.xsd
) से तय किया जाता है. रेफ़रंस के लिए, नीति के स्कीमा GitHub पर उपलब्ध हैं.