আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য
ক্যাশিং হল ভবিষ্যতের রেফারেন্সের জন্য ক্যাশে নামক স্টোরেজ এরিয়ায় সাময়িকভাবে ডেটা স্টোর করার একটি প্রসেস। ডেটা ক্যাশে করলে পারফর্ম্যান্সের ক্ষেত্রে অনেক সুবিধা পাওয়া যায়, কারণ এটি:
- ডেটা আরও দ্রুত রিট্রিভ করা যায়
- বারবার ডেটা রিজেনারেট করা এড়িয়ে প্রসেসিং টাইম কমায়
- ব্যাকএন্ড সার্ভারে API অনুরোধ পাঠানো আটকায় এবং এর ফলে ব্যাকএন্ড সার্ভারের উপর ওভারহেড কমে যায়
- সিস্টেম/অ্যাপ্লিকেশন রিসোর্স আরও ভালোভাবে ব্যবহার করতে দেয়
- API-এর উত্তর দেওয়ার সময় উন্নত করে
যেসব ডেটা খুব ঘন ঘন পরিবর্তন হয় না এবং যেগুলি আমাদের ঘন ঘন অ্যাক্সেস করতে হয়, সেইসব ডেটা স্টোর করার জন্য আমরা ক্যাশে ব্যবহার করার সাজেশন দিই।
Apigee Edge, রানটাইমে ডেটা ক্যাশেতে সেভ করার সুবিধা দেয়, এর ফলে ডেটা স্থায়ী হয় এবং আরও দ্রুত রিট্রিভ করা যায়। PopulateCache নীতি, LookupCache নীতি, InvalidateCache নীতি এবং ResponseCache নীতির মাধ্যমে ক্যাশিং ফিচার উপলভ্য করা হয়।
এই বিভাগে, আসুন রেসপন্স ক্যাশ নীতি সম্পর্কে জেনে নেওয়া যাক। Apigee Edge প্ল্যাটফর্মে রেসপন্স ক্যাশে নীতি আপনাকে ব্যাকএন্ড সার্ভার থেকে পাওয়া রেসপন্স ক্যাশে করতে দেয়। ক্লায়েন্ট অ্যাপ্লিকেশন যদি একই ব্যাকএন্ড রিসোর্সের জন্য বারবার অনুরোধ করে এবং রিসোর্সটি নির্দিষ্ট সময় অন্তর আপডেট হয়, তাহলে আমরা এই নীতি ব্যবহার করে এইসব উত্তর ক্যাশে করতে পারি। উত্তর ক্যাশে নীতি ক্যাশে করা উত্তর রিটার্ন করতে সাহায্য করে এবং এর ফলে অপ্রয়োজনীয়ভাবে ব্যাকএন্ড সার্ভারে অনুরোধ ফরওয়ার্ড করা এড়ানো যায়।
রেসপন্স ক্যাশে নীতি:
- ব্যাকএন্ডে পৌঁছানো অনুরোধের সংখ্যা কমায়
- নেটওয়ার্ক ব্যান্ডউইথ কমায়
- API পারফর্ম্যান্স ও উত্তর দেওয়ার সময় উন্নত করে
অ্যান্টিপ্যাটার্ন
ResponseCache নীতি আপনাকে ডিফল্ট হিসেবে যেকোনও সম্ভাব্য স্ট্যাটাস কোড সহ HTTP উত্তর ক্যাশে করতে দেয়। এর অর্থ হল, সফল ও ত্রুটি সংক্রান্ত উত্তর, দু'টিই ক্যাশে করা যেতে পারে।
ডিফল্ট কনফিগারেশন সহ এখানে একটি নমুনা রেসপন্স ক্যাশে নীতি দেওয়া হল:
<!-- /antipatterns/examples/1-1.xml --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache"> <DisplayName>TargetServer ResponseCache</DisplayName> <CacheKey> <Key Fragment ref="request.uri" /></CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec> </ExpirySettings> <CacheResource>targetCache</CacheResource> </ResponseCache>
রেসপন্স ক্যাশে নীতি তার ডিফল্ট কনফিগারেশনে সমস্যার উত্তর ক্যাশে করে। তবে, এর ক্ষতিকর প্রভাব সম্পর্কে যথেষ্ট চিন্তা না করে এরর রেসপন্স ক্যাশে করা উচিত নয়, কারণ:
- পরিস্থিতি ১: সাময়িক, অজানা সময়ের জন্য ব্যর্থতা ঘটে এবং আমরা
ক্যাশিংয়ের কারণে সমস্যা সমাধান হয়ে যাওয়ার পরেও
ভুল সংক্রান্ত উত্তর পাঠানো চালিয়ে যেতে পারি
অথবা
- পরিস্থিতি ২: ব্যর্থতা একটি নির্দিষ্ট সময়সীমার জন্য দেখা যাবে, তারপরে সমস্যা সমাধান হয়ে গেলে ক্যাশিং রেসপন্স এড়াতে আমাদের কোড পরিবর্তন করতে হবে
এই দুটি পরিস্থিতি আরও বিস্তারিতভাবে আলোচনা করে বিষয়টি ব্যাখ্যা করা যাক।
পরিস্থিতি ১: সাময়িক ব্যাকএন্ড/রিসোর্স সংক্রান্ত সমস্যা
মনে রাখবেন, ব্যাকএন্ড সার্ভারে সমস্যা হওয়ার কারণগুলির মধ্যে একটি হল:
- নেটওয়ার্কের সাময়িক সমস্যা
- ব্যাকএন্ড সার্ভার অত্যন্ত ব্যস্ত এবং সাময়িকভাবে অনুরোধের উত্তর দিতে পারছে না সময়
- অনুরোধ করা ব্যাকএন্ড রিসোর্স সাময়িকভাবে সরিয়ে দেওয়া/উপলভ্য নাও থাকতে পারে
- অস্থায়ী সময়ের জন্য প্রসেসিং টাইম বেশি হওয়ার কারণে ব্যাকএন্ড সার্ভার ধীরে ধীরে উত্তর দিচ্ছে, ইত্যাদি
এইসব ক্ষেত্রে, কতক্ষণ ধরে ব্যর্থতা চলবে তা অজানা এবং তারপরে আমরা সফল উত্তর পেতে শুরু করতে পারি। আমরা যদি সমস্যার উত্তর ক্যাশে করি, তাহলে ব্যাকএন্ড সার্ভারের সমস্যা সমাধান হয়ে গেলেও আমরা ব্যবহারকারীদের কাছে সমস্যার উত্তর পাঠানো চালিয়ে যেতে পারি।
পরিস্থিতি ২: দীর্ঘস্থায়ী বা স্থায়ী ব্যাকএন্ড/রিসোর্স সংক্রান্ত সমস্যা
ধরে নিন যে আমরা জানি ব্যাকএন্ডে সমস্যাটি একটি নির্দিষ্ট সময়ের জন্য হয়েছে। যেমন, আপনি জানেন যে:
- ১ ঘণ্টার জন্য নির্দিষ্ট ব্যাকএন্ড রিসোর্স উপলভ্য থাকবে না
অথবা
- সাইট হঠাৎ বন্ধ হয়ে যাওয়া, স্কেলিং সংক্রান্ত সমস্যা, রক্ষণাবেক্ষণ, আপগ্রেড ইত্যাদি কারণে ব্যাকএন্ড সার্ভার ২৪ ঘণ্টা সরিয়ে দেওয়া/উপলভ্য না থাকা।
এই তথ্যের সাহায্যে, আমরা Response Cache নীতিতে ক্যাশে এক্সপায়ার হওয়ার সময় সঠিকভাবে সেট করতে পারি, যাতে আমরা ভুল উত্তরগুলি দীর্ঘ সময়ের জন্য ক্যাশে না করি। তবে, ব্যাকএন্ড সার্ভার/রিসোর্স আবার উপলভ্য হলে, ক্যাশিং এরর রেসপন্স এড়াতে আমাদের নীতিতে পরিবর্তন করতে হবে। এর কারণ হল, ব্যাকএন্ড সার্ভারে অস্থায়ী/একবার ঘটা কোনও সমস্যা হলে, আমরা উত্তরটি ক্যাশে করে রাখব এবং উপরে ১ নম্বর পরিস্থিতিতে ব্যাখ্যা করা সমস্যাটি আমাদের হবে।
প্রভাব
- ক্যাশিং সংক্রান্ত সমস্যার উত্তর, ব্যাকএন্ড সার্ভারে সমস্যার সমাধান হয়ে যাওয়ার পরেও সমস্যার উত্তর পাঠাতে পারে
- ব্যবহারকারীরা কোনও সমস্যার কারণ খুঁজে বের করার জন্য অনেক চেষ্টা করতে পারেন, কিন্তু তারা জানেন না যে ব্যাকএন্ড সার্ভার থেকে পাওয়া ভুল উত্তর ক্যাশে করার কারণে এটি হয়েছে
পেশাদার পদ্ধতি
- উত্তর ক্যাশে সমস্যার উত্তর সেভ করবে না। নিচের কোড
স্নপেটে দেখানো হয়েছে যে, ভুল উত্তর ক্যাশে করা আটকাতে
ResponseCache নীতিতে
<ExcludeErrorResponse>এলিমেন্টtrueহিসেবে সেট করা আছে কিনা তা নিশ্চিত করুন। এই কনফিগারেশনের মাধ্যমে, শুধু ডিফল্ট সাকসেস কোড 200 থেকে 205-এর উত্তরই (সাকসেস কোড পরিবর্তন না করা হলে) ক্যাশে করা হবে।<!-- /antipatterns/examples/1-2.xml --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache"> <DisplayName>TargetServerResponseCache</DisplayName> <CacheKey> <KeyFragment ref="request.uri" /> </CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec> </ExpirySettings> <CacheResource>targetCache</CacheResource> <ExcludeErrorResponse>true</ExcludeErrorResponse> </ResponseCache>
- নির্দিষ্ট কোনও কারণে ত্রুটি সংক্রান্ত উত্তর ক্যাশে করার প্রয়োজন হলে, আপনি
ব্যর্থতা কতক্ষণ ধরে দেখা যাবে তার সর্বাধিক/সঠিক সময়সীমা নির্ধারণ করতে পারবেন (যদি
সম্ভব হয়):
- ভুল উত্তর যতক্ষণ দেখা যাবে তার থেকে বেশি সময় ধরে যে সেগুলি ক্যাশে করা হচ্ছে না তা নিশ্চিত করতে, উপযুক্তভাবে মেয়াদ শেষ হওয়ার সময় সেট করুন।
-
<ExcludeErrorResponse>এলিমেন্ট ছাড়া ভুলের উত্তর ক্যাশে করতে ResponseCache নীতি ব্যবহার করুন।
ব্যাকএন্ড সার্ভার ব্যর্থতা যে স্বল্প/অস্থায়ী সময়ের জন্য নয়, সেই ব্যাপারে আপনি নিশ্চিত হলেই এটি করুন।
- Apigee ব্যাকএন্ড সার্ভার থেকে পাওয়া 5xx উত্তর ক্যাশে করার সাজেশন দেয় না।