Postsharp। हम कैशिंग समस्या का समाधान करते हैं

कभी-कभी ऐसी परिस्थितियां होती हैं जिनमें एक निश्चित ऑपरेशन के संचालन को गति देने का कोई तरीका नहीं होता है। यह बाहरी वेब सर्वर पर स्थित कुछ सेवा पर निर्भर हो सकता है, या यह एक ऑपरेशन हो सकता है जो प्रोसेसर को अधिक भार देता है। या यह त्वरित संचालन हो सकता है, हालांकि, उनका समानांतर ऑपरेशन आपके कंप्यूटर से सभी प्रदर्शन संसाधनों को चूस सकता है। कैशिंग का उपयोग करने के कई कारण हैं। यह ध्यान दिया जाना चाहिए कि PostSharp , शुरू में आपके लिए किसी भी कैशिंग ढांचे के लिए समाधान प्रदान नहीं करता है, यह सिर्फ आपको किसी भी थकाऊ कार्यों के बिना, परिमाण के इस कार्य आदेशों को तेज करने की अनुमति देता है, जैसे कि प्रोग्राम स्रोत कोड पर सभी कैशिंग के लिए जिम्मेदार कोड सेट करना। यह आपको इस समस्या को हल करने की अनुमति देता है, कक्षाओं में कार्यों को रखकर और उन्हें पुन: उपयोग करने की अनुमति देता है।



मान लीजिए मैं कार डीलरशिप वेबसाइट पर यह पता लगाना चाहता हूं कि इस कार डीलरशिप पर बिक्री के लिए कितनी कारें हैं। ऐसा करने के लिए, मैं एक एप्लिकेशन का उपयोग करूंगा जो सर्वर से सैलून की कीमत सूची से डाउनलोड करेगा, जो एक निश्चित मेक, मॉडल और निर्माण के वर्ष की कारों के लिए डिज़ाइन किया गया है। यदि मूल्य सूची (हमारे उदाहरण के हिस्से के रूप में) के मूल्य बहुत बार बदलते हैं, तो मैं इस मूल्य सूची के मूल्यों को प्राप्त करने के लिए वेब सेवा का उपयोग करूंगा। मान लीजिए, उसी समय, वेब सेवा बहुत धीमी है, लेकिन मैं बहुत सी कारों का अनुरोध करना चाहता हूं। जैसा कि आप जानते हैं, मैं किसी और की वेब सेवा को तेज़ नहीं बना सकता, लेकिन मैं स्टोर से लौटाए गए डेटा को कैश कर सकता हूं, इस प्रकार अनुरोधों की संख्या कम हो सकती है।
चूंकि PostSharp की मुख्य विशेषताओं में से एक विधि कॉल का "अवरोधन" है, अर्थात्। विधि में इस तरह से लागू करना कि हम विधि निकाय के काम से पहले और बाद में अपने कोड को निष्पादित कर सकें, हम इस ढांचे का उपयोग कैशिंग कार्य को कार्यान्वित करने के लिए करेंगे:

[ Serializable ]
public class CacheAttribute : MethodInterceptionAspect
{
[NonSerialized]
private static readonly ICache _cache;
private string _methodName;

static CacheAttribute()
{
if (!PostSharpEnvironment.IsPostSharpRunning)
{
// one minute cache
_cache = new StaticMemoryCache( new TimeSpan (0, 1, 0));
// use an IoC container/service locator here in practice
}
}

public override void CompileTimeInitialize(MethodBase method, AspectInfo aspectInfo)
{
_methodName = method.Name;
}

public override void OnInvoke(MethodInterceptionArgs args)
{
var key = BuildCacheKey(args.Arguments);
if (_cache[key] != null )
{
args.ReturnValue = _cache[key];
}
else
{
var returnVal = args.Invoke(args.Arguments);
args.ReturnValue = returnVal;
_cache[key] = returnVal;
}
}

private string BuildCacheKey(Arguments arguments)
{
var sb = new StringBuilder ();
sb.Append(_methodName);
foreach ( var argument in arguments.ToArray())
{
sb.Append(argument == null ? "_" : argument.ToString());
}
return sb.ToString();
}
}

* This source code was highlighted with Source Code Highlighter .

मैं संकलित समय पर विधि का नाम सहेजता हूं और रन-टाइम में कैश सेवा को इनिशियलाइज़ करता हूं। कैशिंग के लिए एक कुंजी के रूप में, मैं विधि के नाम के साथ-साथ विधि के सभी मापदंडों के मूल्यों का उपयोग करूँगा, एक स्थान के साथ सूचीबद्ध किया जाएगा (बिल्डकैचे विधि का कोड देखें), जो प्रत्येक विधि और मापदंडों के प्रत्येक सेट के लिए अद्वितीय होगा। OnInvoke पद्धति में, मैं जांचता हूं कि क्या कैश में प्राप्त कुंजी मौजूद है, और यदि पहले से ही कुंजी मौजूद है, तो कैश से मूल्य का उपयोग करें। अन्यथा, मैं अगली कॉल तक काम के परिणाम को कैश करने के लिए मूल विधि के कोड को कॉल करता हूं।
मेरे उदाहरण में, एक GetCarValue विधि है, जिसे एक कार के बारे में जानकारी प्राप्त करने के लिए एक वेब सेवा कॉल का अनुकरण करने के लिए डिज़ाइन किया गया है। इस पद्धति में ऐसे मानदंड हैं जो विभिन्न प्रकार के मान ले सकते हैं, इसलिए इसे हर बार (हमारे उदाहरण में, केवल उन मामलों में जहां कोई कैश नहीं किया गया है) अलग परिणाम लौटा सकते हैं:

[Cache]
public decimal GetCarValue( int year, CarMakeAndModel carType)
{
// simulate web service time
Thread.Sleep(_msToSleep);

int yearsOld = Math .Abs( DateTime .Now.Year - year);
int randomAmount = ( new Random ()).Next(0, 1000);
int calculatedValue = baselineValue - (yearDiscount*yearsOld) + randomAmount;
return calculatedValue;
}

* This source code was highlighted with Source Code Highlighter .

इस पहलू के बारे में कुछ नोट्स:

• मैं मेथोडोडबाउंडरीअस्पेक्ट का उपयोग मेथोडेरिसेप्शन एस्पेक्ट के बजाय कर सकता हूं: दोनों एप्रोच सही होंगे। बस इस मामले में, मैंने अपनी पसंद को आसान बनाने के लिए MethodInterceptionAspect को चुना, कार्यक्रम की आवश्यकताओं को कवर किया
• याद रखें कि चूंकि कैश को लोड करने और उसे इनिशियलाइज़ करने का कोई मतलब नहीं है, जबकि PostSharp चल रहा है (नहीं जबकि एप्लिकेशन चल रहा है), हमें यह जांचना होगा कि PostSharp चल रहा है या नहीं। निर्भरता को लोड करने का एक और तरीका कोड को RuntimeInitialize में डालना है।
• यह पहलू कैशिंग कार्यों में 'आउट' और 'रेफ' मापदंडों का उपयोग करना संभव नहीं बनाता है। बेशक, यह किया जा सकता है, लेकिन यह मुझे लगता है कि ऐसे कार्यों में पैरामीटर 'आउट' और 'रेफ' का उपयोग नहीं किया जाना चाहिए, और यदि आप मुझसे सहमत हैं, तो उनके कार्यान्वयन पर समय बर्बाद न करें।

संकलन समय पर जाँच करता है

हमेशा विकल्प होते हैं जब कैशिंग एक अच्छा विचार नहीं है। उदाहरण के लिए, जब कोई विधि स्ट्रीम लौटाती है, IEnumerable, IQueryable, आदि।
इंटरफेस। इसलिए, ऐसे मूल्यों को कैश नहीं किया जा सकता है। ऐसा करने के लिए, आपको CompileTimeValidate विधि को ओवरराइड करना होगा, उदाहरण के लिए, इस तरह:

public override bool CompileTimeValidate(MethodBase method)
{
var methodInfo = method as MethodInfo;
if (methodInfo != null )
{
var returnType = methodInfo.ReturnType;
if (IsDisallowedCacheReturnType(returnType))
{
Message.Write(SeverityType.Error, "998" ,
"Methods with return type {0} cannot be cached in {1}.{2}" ,
returnType.Name, _className, _methodName);
return false ;
}
}
return true ;
}

private static readonly IList DisallowedTypes = new List
{
typeof ( Stream ),
typeof ( IEnumerable ),
typeof (IQueryable)
};
private static bool IsDisallowedCacheReturnType(Type returnType)
{
return DisallowedTypes.Any(t => t.IsAssignableFrom(returnType));
}

* This source code was highlighted with Source Code Highlighter .

इस प्रकार, यदि कोई भी डेवलपर उन तरीकों पर कैशिंग लागू करने का प्रयास करता है, जिन्हें कैश नहीं किया जाना चाहिए, तो उसे एक संकलन त्रुटि संदेश प्राप्त होगा। वैसे, यदि आप किसी प्रकार के लिए IsAssignableFrom का उपयोग करते हैं, तो आप उन वर्गों और इंटरफेस को भी कवर करते हैं जो इसे पर्याप्त रूप से प्राप्त करेंगे। यानी हमारे मामले में, इस तरह के FileStream, IEnumerable, आदि को भी कवर किया जाएगा।

मल्टीटास्किंग

महान, इस बिंदु पर हमारे पास पहले से ही उन सभी तरीकों के लिए कैशिंग जोड़ने का एक शानदार समाधान है जिनकी आवश्यकता है। हालाँकि, क्या आपने कभी इस कैशिंग पहलू में छिपी एक संभावित समस्या के बारे में सोचा है? मल्टीटास्किंग एप्लिकेशन (जैसे वेबसाइट) में, कैशिंग अपने काम का एक उत्कृष्ट कार्य करता है, क्योंकि पहले "उपयोगकर्ता" कैश तक पहुंचने के बाद, प्रत्येक बाद के "उपयोगकर्ता" कैश एक्सेस की गति का उपयोग करने से सभी क्रीम खींचता है। हालांकि, क्या होता है जब दो उपयोगकर्ता एक ही समय में एक ही जानकारी प्राप्त करने की कोशिश करते हैं? कैशिंग पहलू में जो हमने अभी विकसित किया है, इसका मतलब यह होगा कि दोनों उपयोगकर्ता कम से कम एक ही कैश मान की गणना करेंगे। एक कार शॉप वेबसाइट के लिए, यह बहुत प्रासंगिक नहीं है, लेकिन यदि आपके पास एक ही समय में एक ही जानकारी का अनुरोध करने वाले सैकड़ों या हजारों आगंतुकों के लोड के साथ एक वेब सर्वर है, तो कैशिंग कार्य बहुत प्रासंगिक हो जाता है। यदि वे सभी एक ही समय में अनुरोध करते हैं, तो हमारा कैश लगातार समान मूल्यों की गणना करेगा।

इस समस्या का एक सरल समाधान यह होगा कि कैश का उपयोग करने पर हर बार "लॉक" का उपयोग किया जाए। हालांकि, लॉकिंग एक महंगा और धीमा ऑपरेशन है, और यह बेहतर है अगर हम पहले कैश में एक कुंजी के अस्तित्व की जांच करते हैं, और उसके बाद ही इसे ब्लॉक करते हैं। हालांकि, इस मामले में, एक संभावना है कि कई थ्रेड्स कैश में एक कुंजी की अनुपस्थिति के लिए एक साथ जांच कर सकते हैं और इस कुंजी की गणना करने के लिए जा सकते हैं, इसलिए हमें कुंजी को दो बार ( डबल-चेकिंग लॉकिंग ) के अस्तित्व की जांच करनी चाहिए, लॉक कोड के बाहर और उसके अंदर:

[ Serializable ]
public class CacheAttribute : MethodInterceptionAspect
{
[NonSerialized] private object syncRoot;

public override void RuntimeInitialize(MethodBase method)
{
syncRoot = new object ();
}

public override void OnInvoke(MethodInterceptionArgs args)
{
var key = BuildCacheKey(args.Arguments);
if (_cache[key] != null )
{
args.ReturnValue = _cache[key];
}
else
{
lock (syncRoot)
{
if (_cache[key] == null )
{
var returnVal = args.Invoke(args.Arguments);
args.ReturnValue = returnVal;
_cache[key] = returnVal;
}
else
{
args.ReturnValue = _cache[key];
}
}
}
}
}

* This source code was highlighted with Source Code Highlighter .

यह थोड़ा दोहरावदार दिखता है, लेकिन इस मामले में, उच्च-लोड समाधानों के लिए प्रदर्शन में सुधार करने के लिए यह एक शानदार समाधान है। कैश को ब्लॉक करने के बजाय, मैं कुछ निजी ऑब्जेक्ट को ब्लॉक कर रहा हूं जो केवल उस विधि के लिए विशिष्ट है जिस पहलू को लागू किया गया है। यह सब कैश का उपयोग करते समय तालों की संख्या को कम करता है।
आशा है कि आप भ्रमित नहीं हैं? कई कार्यों के समानांतर निष्पादन की समस्याएं भ्रामक हो सकती हैं, लेकिन कई अनुप्रयोगों में यह एक वास्तविकता है। इस पहलू के साथ, आपको अब अपनी खुद की गलतियों या डेवलपर्स की गलतियों के बारे में थोड़ी मात्रा में अनुभव करने की कोई चिंता नहीं है। या COBOL पर 30 साल के विकास के अनुभव के साथ नए डेवलपर्स या डेवलपर्स की गलतियों के बारे में और पहली बार सी # देखकर :)। वास्तव में, उन्हें यह जानने की आवश्यकता है कि कैश पहलू के साथ तरीकों को कैसे फ्रेम किया जाए, और उन्हें यह जानने की आवश्यकता नहीं है कि इस तकनीक को कैसे लागू किया जाना चाहिए। और उन्हें नहीं पता होना चाहिए कि उनके तरीकों को कैसे सुरक्षित बनाया जाए। वे संबंधित कार्यों के कार्यान्वयन से विचलित हुए बिना केवल कोड के अपने स्वयं के टुकड़े पर ध्यान केंद्रित करने में सक्षम होंगे।

संदर्भ:

• उत्पाद वेबसाइट: www.sharpcrafters.com
• मूल लेख साइट: 5 तरीके जो PostSharp आपके कोड को हल कर सकते हैं: कैशिंग
• पूर्ण उदाहरण के लिए स्रोत कोड: GitHub
• हम कैशिंग समस्या का समाधान करते हैं
• इंटेल ब्लॉग्स: पोस्टशार्प। भाग 1
• इंटेल ब्लॉग्स: पोस्टशार्प। विकल्प
• पहलू उन्मुख प्रोग्रामिंग बनाम निर्भरता इंजेक्शन
• PostSharp। लॉगिंग और ऑडिट कार्य