मैंने माइक्रोसॉफ्ट प्रलेखन में कहीं कहीं पढ़ा है कि एएसपी.नेट के की सामग्री web.config को कैश किया गया है। यदि यह सत्य है, जहां यह कैश किया गया है - मेमोरी या डिस्क पर?एएसपी.नेट: web.config कैश किया गया/कैसा है?
और एक फॉलो-अप प्रश्न: क्या मुझे कोई प्रदर्शन विचार करना है, अगर मुझे web.config को गहन रूप से एक्सेस करना है?
यह स्मृति में कैश किया गया है, डिस्क पर कैशिंग कोई समझ नहीं आता है, यह पहले से ही डिस्क पर है।
एएसपी.नेट में सबसे पहले आप यह सुनिश्चित करना चाहते हैं कि आप HttpContext ऑब्जेक्ट के GetSection विधि के माध्यम से कॉन्फ़िगरेशन अनुभागों तक पहुंचें (यह एएसपी.नेट द्वारा प्रबंधित कैश की गई प्रतियों का उपयोग करता है)।
कॉन्फ़िगरेशन मानों तक पहुंचने का प्रदर्शन अनुभाग ऑब्जेक्ट (गेटसेक्शन द्वारा लौटाई गई वस्तु) के आंतरिक कार्यान्वयन का एक कार्य है। एक ConfigurationSection बस एक डोम नोड के लिए रैपर के रूप में कार्य कर सकता है जो यह किसी संपत्ति के लिए प्रत्येक अनुरोध पर पढ़ सकता है। ओटीएच यह मूल्य को कैश कर सकता है और परिवर्तनों के लिए देख सकता है।
मेरी सलाह होगा होना अपने कोड सरल रख सकते हैं और मूल्यों आप GetSection के माध्यम से की जरूरत के बजाय कहीं और उनकी कॉपी पकड़ करने का प्रयास का उपयोग लेकिन हर तरह से वस्तु एक अनुरोध करता है, तो की अवधि के लिए GetSection द्वारा वापस लिए एक संदर्भ को बनाए रखने आप इससे कई मूल्य लाने जा रहे हैं।
मुझे लगता है कि web.config स्मृति में कैश किया गया है (System.Web.Configuration से ऑब्जेक्ट उदाहरणों में)। जब .config फ़ाइल बदल जाती है (और इस प्रकार आपके वेब ऐप को पुनः लोड करना) को फिर से लोड किया जाता है।
उन वस्तुओं को मारना आपको प्रदर्शन बाधा देने की संभावना नहीं है। लेकिन अगर आपको पार्सिंग आदि करना है, तो आप पार्स किए गए ऑब्जेक्ट्स को पकड़ना चाहेंगे।
[अतिरिक्त] मैं अच्छी प्रैक्टिस (मुझे कम से कम लगता है) आपके ग्लोबल.एएसएक्स सीएस फाइल में स्थिरताएं बनाने के लिए है। आप application_start विधि में उन गुणों को तुरंत चालू कर सकते हैं और उन्हें अपने वेब ऐप के माध्यम से उपयोग कर सकते हैं। यह आपको अपने कोड में हार्ड-कोडेड स्ट्रिंग (कॉन्फ़िगरेशन कुंजी) का उपयोग करने से रोकता है।
यह स्मृति में कैश किया गया है। डिस्क पर कैशिंग कुछ ऐसी चीज के लिए बहुत अधिक समझ नहीं लेती है जो अक्सर उपयोग की जाती है और पहले से ही एक प्रारूप में है जहां आप इसे आसानी से संग्रहीत डेटा संरचना में बदल सकते हैं। मेरी सलाह यह है कि इसे आसानी से एक्सेस करना होगा क्योंकि यह जितना तेज़ होगा उतना तेज़ होगा जितना आप इसे स्टोर करने और शायद तेज़ करने के लिए करेंगे।
मेरी सलाह यह है कि डेटा को कैश किए जाने के सरल कारण के लिए किसी भी अन्य चर की तरह इसका उपयोग करना होगा। यदि आप वैश्विक.एक्सएक्स में स्थिर चर बनाते हैं तो आप स्वयं को अधिक कोड लिखने के लिए मजबूर कर रहे हैं। कोई फर्क नहीं पड़ता कि आप कैसे योजनाबद्ध हैं, यह अत्यधिक संभावना है कि आप विकास चरण के दौरान अक्सर एपॉन्फिग में चर जोड़ते हैं।
एएसपी .NET में 2 प्रकार के कैशिंग हैं।
आवेदन कैशिंग - प्रदान की गई सर्वर पर पेज कैश - आंतरिक वस्तु कैश memorylimitation, समय सीमा और अन्य निर्भरता
पृष्ठ आउटपुट कैशिंग पर आधारित है। उनमें से मेमोरी आधारित हैं; डिस्क नहीं
मुझे नहीं लगता कि आप ओपी के मूल प्रश्न को समझ गए हैं ... –
ASP.NET में, <appSettings> खंड 1 पहुँच के बाद स्मृति को कैश किया गया है:
वेब.config फ़ाइल के अपडेट होने पर ASP.NET एप्लिकेशन को पुनरारंभ करता है।
डिस्क पर एक क्रमबद्ध तरीके से हो सकता है ... ठीक है, ठीक है, यह मूर्खतापूर्ण है, मुझे पता है। ऐसा नहीं सोचा था क्योंकि मैंने लिखा था ... :-) – splattne
रुको ... क्या मैं पागल हूँ? मैं RedGate परावर्तक में HttpContext.GetSection को देख रहा हूं, और ऐसा लगता है कि यह ConfigManager.GetSection को आंतरिक रूप से कॉल करता है, जो ऐसा नहीं लगता है कि यह किसी भी चीज़ को कैश करता है। अगर मुझे कुछ याद आया तो कृपया मुझे बताएं। –
@Dan: आप यह निर्दिष्ट नहीं करते कि आप कौन सा संस्करण देख रहे हैं, 2.0.0.0 'कॉन्फ़िगरेशन प्रबंधक' पर वापस आ गया है लेकिन इस संदर्भ में अनुभाग प्राप्त करने के लिए 'कैश्डपाथडेटा' का उपयोग करेगा। इसका कारण यह है कि कई 'web.config' फ़ाइलें शामिल हो सकती हैं (वर्तमान पथ में प्रत्येक फ़ोल्डर में से एक), पथ के लिए प्रस्तुत किए जाने वाले कॉन्फ़िगर की वास्तविक स्थिति उन सभी से बनी है। – AnthonyWJones