performance - AppFabric कैशिंग-DataCacheFactory और DataCache का उचित उपयोग




caching (2)

मैं ऐपफ़ैब्रिक कैशिंग कॉल के लिए डेटाैकैच और डेटाैकैच फैक्ट्री के उपयोग की व्यवस्था करने के लिए सबसे अधिक प्रभावी तरीका ढूंढ रहा हूं, 400 से 700 कैश प्रति पेज लोड (और मुश्किल से कोई भी रखता है) के बीच। ऐसा लगता है कि एक स्थिर डेटाकैच फैक्ट्री (या संभवतः एक राउंड-रॉबिन सेटअप में एक जोड़े) का उपयोग करने का तरीका है।

क्या मैं प्रत्येक डेटा कैश ऑब्जेक्ट अनुरोध के लिए GetCache ("cacheName") को कॉल करता हूं, या क्या मैं डेटाकैच फैक्ट्री को प्रारंभ करने के दौरान एक स्थिर बना देता हूं और सभी कॉल के लिए इसका उपयोग करता हूं?

क्या मुझे अपवादों को संभालना है, असफल कोडों की जांच करना और पुनः प्रयास करना है?

क्या मुझे विवाद पर विचार करना होगा जब एक से अधिक धागे कैश स्टोर का उपयोग करने की कोशिश करते हैं और वही आइटम चाहते हैं (कुंजी के द्वारा)?

क्या कोई ऐसा दस्तावेज है जो इस के डिजाइन और उपयोग की उचित खोज करता है?

कुछ जानकारी जो मैंने मंच से अब तक एकत्र की है:

http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/98d4f00d-3a1b-4d7c-88ba-384d3d5da915

"फैक्ट्री बनाने में क्लस्टर से जुड़ना शामिल है और इसमें कुछ समय लग सकता है। लेकिन एक बार जब आपके पास फैक्ट्री ऑब्जेक्ट और कैश है जिसके साथ आप काम करना चाहते हैं, तो आप बस उन ऑब्जेक्ट्स को फिर से इस्तेमाल कर सकते हैं और कैश में आ सकते हैं, और आपको चाहिए बहुत तेज प्रदर्शन देखें। "

http://social.msdn.microsoft.com/Forums/en-US/velocity/thread/0c1d7ce2-4c1b-4c63-b525-5d8f98bb8a49

"एकल डेटा कैश फैक्ट्री (सिंगलटन) बनाना कई डेटा कैश फैक्ट्री बनाने से अधिक प्रदर्शन कर रहा है। आपको प्रत्येक कॉल के लिए डेटा कैश फैक्टरी नहीं बनाना चाहिए, इसमें प्रदर्शन हिट होगा।"

"कृपया अपने सिंगलटन में राउंड-रॉबिन एल्गोरिदम (3/4/5 फैक्ट्री इंस्टेंस होने) को समाहित करने का प्रयास करें और लोड-टेस्ट परिणामों की तुलना करें।"

http://blogs.msdn.com/b/velocity/archive/2009/04/15/pushing-client-performance.aspx

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

यहां तक ​​कि अब तक उपयोग में क्या है ... संपत्ति को बुलाया जाता है और यदि वापसी मूल्य शून्य नहीं है तो एक ऑपरेशन किया जाता है।

private static DataCache Cache
{
    get
    {
        if (_cacheFactory == null)
        {
            lock (Sync)
            {
                if (_cacheFactory == null)
                {
                    try
                    {
                        _cacheFactory = new DataCacheFactory();
                    }
                    catch (DataCacheException ex)
                    {
                        if (_logger != null)
                        {
                            _logger.LogError(ex.Message, ex);
                        }
                    }
                }
            }
        }

        DataCache cache = null;

        if (_cacheFactory != null)
        {
            cache = _cacheFactory.GetCache(_cacheName);
        }

        return cache;
    }
}

Microsoft AppFabric फ़ोरम पर यह प्रश्न देखें: http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/e0a0c6fb-df4e-499f-a023-ba16afb6614f


क्या मैं प्रत्येक डेटा कैश ऑब्जेक्ट अनुरोध के लिए GetCache ("cacheName") को कॉल करता हूं, या क्या मैं डेटाकैच फैक्ट्री को प्रारंभ करने के दौरान एक स्थिर बना देता हूं और सभी कॉल के लिए इसका उपयोग करता हूं?

मुझे लगता है कि वास्तव में जवाब होना चाहिए; इसे दोनों तरीकों से आजमाएं और देखें कि कोई अंतर है या नहीं, लेकिन एक स्थिर डेटा कैश मुझे हर कॉल के लिए GetCache के संबंधित कॉल से अधिक समझने के लिए प्रतीत होता है।

'पुशिंग क्लाइंट परफॉर्मेंस' आलेख से पता चलता है कि वहां एक मीठा स्थान है जहां डेटा कैश फैक्ट्री इंस्टेंस की संख्या आपको अधिकतम प्रदर्शन देती है, जिसके अतिरिक्त मेमोरी ओवरहेड आपके खिलाफ काम करना शुरू कर देता है - यह शर्म की बात है कि उन्होंने कोई दिशानिर्देश नहीं दिया (या यहां तक ​​कि अंगूठे का नियम भी ) जहां यह जगह हो सकती है।

मैं प्रदर्शन को अधिकतम करने के लिए किसी भी दस्तावेज़ीकरण में नहीं आया हूं - मुझे लगता है कि अभी तक इन दिशानिर्देशों के लिए ऐपफैब्रिक अभी भी बहुत नया है। मैंने प्रो ऐपफैब्रिक पुस्तक के लिए सामग्री में एक नज़र डाली थी , लेकिन कैशिंग (वेग) टुकड़े की बजाय ऐपफैब्रिक के वर्कफ़्लो (डबलिन) पक्ष के साथ आमतौर पर यह अधिक चिंतित लगता है।

एक बात मैं हालांकि कहूंगा: क्या आपके लिए 'चंकीयर' ऑब्जेक्ट्स को कैश करने की कोई संभावना है ताकि आप कम कॉल कर सकें? क्या आप अलग-अलग ऑब्जेक्ट्स के बजाय संग्रह कैश कर सकते हैं और फिर क्लाइंट पर संग्रह को अनपैक कर सकते हैं? प्रति पृष्ठ लोड 700 कैश मुझे एक बड़ी संख्या के रूप में लगता है!


फ़ोरम पोस्ट का उत्तर यहां दिया गया है:

नमस्ते। देरी से प्रतिक्रिया के लिए खेद है, लेकिन मैं कहना चाहता हूं कि ये बहुत अच्छे प्रश्न हैं और शायद दूसरों के लिए उपयोगी होंगे।

जब तक आपको अलग-अलग कॉन्फ़िगरेशन की आवश्यकता न हो, तब तक एक से अधिक DataCacheFactory प्रति थ्रेड की आवश्यकता नहीं होनी चाहिए। उदाहरण के लिए, यदि आप DataCacheFactoryConfiguration क्लास के साथ DataCacheFactory को प्रोग्रामेटिक रूप से कॉन्फ़िगर करते हैं, तो हो सकता है कि आप उस व्यक्ति को बनाना चाहें जिसमें स्थानीय कैश सक्षम है और दूसरा ऐसा नहीं है। इस मामले में, आप अपने परिदृश्य के लिए आवश्यक कॉन्फ़िगरेशन के आधार पर विभिन्न DataCacheFactory ऑब्जेक्ट्स का उपयोग करेंगे। लेकिन कॉन्फ़िगरेशन में मतभेदों के अलावा, आपको एकाधिक डेटा कैशफ़ैक्टरीज बनाकर प्रदर्शन लाभ नहीं दिखना चाहिए।

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

एक बार आपके पास DataCacheFactory हो जाने के बाद, आपको एकाधिक डेटा कैश ऑब्जेक्ट्स प्राप्त करने के लिए GetCache () कई बार कॉल करने की आवश्यकता नहीं है। एक ही फैक्ट्री पर उसी कैश के लिए GetCache () पर प्रत्येक कॉल एक ही डेटा कैश ऑब्जेक्ट देता है। साथ ही, आपके पास DataCache ऑब्जेक्ट होने के बाद, आपको इसके लिए DataCacheFactory को कॉल करना जारी रखने की आवश्यकता नहीं है। बस डेटा कैश ऑब्जेक्ट को स्टोर करें और इसका उपयोग जारी रखें। हालांकि, DataCacheFactory ऑब्जेक्ट को डिस्पोजेक्ट न करने दें। DataCache ऑब्जेक्ट का जीवन DataCacheFactory ऑब्जेक्ट से जुड़ा हुआ है।

आपको अनुरोध प्राप्त करने के साथ विवाद के बारे में चिंता करने की ज़रूरत नहीं है। हालांकि, पुट / एड अनुरोधों के साथ, यदि एकाधिक डेटा कैश क्लाइंट एक ही समय में एक ही कुंजी को अपडेट कर रहे हैं तो विवाद हो सकता है। इस मामले में, आपको ERRCA0017, RetryLater के त्रुटि कोड और ES0005 के एक substatus, KeyLatched के साथ अपवाद मिलेगा। हालांकि, आप आसानी से अपवाद हैंडलिंग जोड़ सकते हैं और फिर से अद्यतन करने का प्रयास करने के लिए तर्क पुनः प्रयास कर सकते हैं जब इन जैसी त्रुटियां होती हैं। यह विभिन्न substatus मूल्यों के साथ RetryLater कोड के लिए किया जा सकता है। अधिक जानकारी के लिए, http://msdn.microsoft.com/en-us/library/ff637738.aspx देखें। आप GetAndLock () और PutAndUnlock () API का उपयोग करके निराशावादी लॉकिंग का भी उपयोग कर सकते हैं। यदि आप इस विधि का उपयोग करते हैं तो यह सुनिश्चित करना आपकी ज़िम्मेदारी है कि सभी कैश क्लाइंट निराशावादी लॉकिंग का उपयोग करें। एक पुट () कॉल उस ऑब्जेक्ट को मिटा देगा जो पहले GetAndLock () द्वारा लॉक किया गया था।

आशा है कि ये आपकी मदद करेगा। जैसे मैंने कहा, हम आशा करते हैं कि जल्द ही कुछ औपचारिक सामग्री में इस तरह के मार्गदर्शन प्राप्त करें। लेकिन इसे तब तक मंच पर साझा करना बेहतर है। धन्यवाद!

जेसन रोथ





appfabric