Configuring IIS for ASP.NET Applications

चूंकि ASP.NET Applications, IIS Web Server के Context में रहते हैं, इसलिए हम IIS पर जिन Settings को Apply करते हैं, उनका प्रभाव हमारे Application की कार्यप्रणाली पर भी पडता है। चलिए, IIS की कुछ ऐसी Settings के बारे में समझने की कोशिश करते हैं, जिनकी जरूरत हमें हमारे Application की Performance को Improve करने के लिए पडती है।

Configuring IIS – Recycling Policies

Application Pool, जो कि हमारे ASP.NET Application को Host करता है, Process Recycling से सम्बंधित होता है। Process Recycling एक Configurable Setting है, जिसके माध्‍यम से हम इस बात को तय करते हैं कि Application Pool व उसमें Contained Applications को कब Restart करना है।

Recycling कोई गलत प्रक्रिया नहीं है और ये किसी Problem को भी Indicate नहीं करता। लेकिन यदि बिना किसी स्पष्‍ट कारण के Recycling बार-बार Perform हो, तो हमारे Application के Performance के लिहाज से ये कोई अच्छा Signal नहीं है।

Process Recycling एक IIS Feature है, जो उन Programming Errors के Against एक Insurance Feature की तरह Use होता है, जिससे हमारा Application Leak Memory, Hang या Slow-Down जैसी समस्याओं को शिकार हो जाता है।

Application Pool के अन्तर्गत बार-बार Worker Process की Recycling करके, Web Server इस बात को Ensure करने की कोशिश करता है Web Server की Service एक औसत स्तर की बनी रहे।

Process Recycling हमेंशा Natural तरीके से अक्सर Perform होते रहना चाहिए ताकि हमारे Web Application की Performance समय-समय पर Normal होती रहे। फिर भी यदि पर्याप्त Process Recycling होने के बावजूद हमारे Application की Performance अनावश्‍यक रूप से प्रभावित हो रही हो, तो उस स्थिति में हमें इसके बारे में सोंचने की जरूरत पडती है।

Worker Process को Recycle करने हेतु Trigger करने के कई कारण हो सकते हैं। लेकिन जो Natural कारण हो सकते हैं, वे सभी निम्न चित्रानुसार दर्शाया Wizard Screens पर दिखाई देने वाले कारण हो सकते हैं:

Application Pool को Regular Intervals पर Recycle किया जा सकता है, जो कि हमारी Default Choice होती है। जबकि हम एक निश्चित संख्‍या में Requests Perform हो जाने के बाद, या एक निश्चित समयाविध के बाद या फिर Enough Memory Consume हो जाने के बाद भी Recycling करने हेतु इस Wizard Screen को Configure कर सकते हैं।

इसके अलावा जब हम Deployed Website में कोई Modification करते हैं अथवा Configuration File को Modify करते हैं या फिर Bin Folder को Modify करते हैं, तो उस स्थिति में भी Application Pool Recycle हो जाता है।

यदि हम हमारी Website में बार-बार छोटे-मोटे Changes करते रहते हैं, तो उस स्थिति में एक निश्चित संख्‍या में Assemblies के Memory में Load हो जाने के बाद भी Application Pool को Recycle करने हेतु Configure किया जा सकता है।

.NET Framework में हम किसी Specific Assembly को Unload नहीं कर सकते। इसलिए जब कोई ASP.NET Page Modify होता है, तो Next Access पर वह File फिर से Recompile होता है, जिसके परिणामस्वरूप फिर से एक नया Assembly Create होता है और ये Newly Created Assembly फिर से AppDomainesa Load हो जाता है।

चूंकि Recompile की संख्‍या Unlimited नहीं होती इसलिए इसे Web.config File में<compilation> Section के अन्‍तर्गत numRecompilesBeforeAppRestart Attribute के माध्‍यम से Set किया जा सकता है। जब Recompiles की संख्‍या इस Set की गई संख्‍या से बढ जाती है, उसके तुरन्त बाद हमारा Application Restart हो जाता है।

Configuring IIS – Unexpected Restarts

उपरोक्तानुसार Discussed विभिन्न कारणों के अलावा किसी Unhandled Exceptions, Timeouts, Low Memory या Treaके अथवा Connection Pool Related Issues की वजह से भी Application Pool Recycle हो जाता है।

सामान्‍यत: Worker Process Recycling एक Defensive Measure होता है जिसे हमारे Application को Shape में बनाए रखने व किसी Typical Trouble को रोकने के लिए Define किया गया है।

Application Restart भी Issues से Free नहीं है क्योंकि इसकी वजह से User का Session पूरी तरह से Destroy हो जाता है। जबकि Session का Destroy होukWeb Application के Hang या पूरी तरह से Crash हो जाने की तुलना में काफी Simple Issue है।

Application Restart एक ऐसी घटना है, जिसे आसानी से Spot किया जाना सम्भव नहीं है। इसलिए जब कभी भी ऐसा लगे कि Process Recycling की वजह से Application की Performance प्रभावित हो रही है, तो सबसे पहले Event Viewer को इस बात के लिए Check किया जाना चाहिए कि कहीं किसी विशेष Information को Track तो नहीं किया जा रहा है। इसके साथ ही Memory Usage अगला वह Feature है, जिसे Check किया जाना चाहिए।

IIS 7.x में हम निम्न चित्रानुसार दिखाई देने वाले “Advanced Settings” Dialog Box के माध्‍यम से इस बात को भी तय कर सकते हैं कि Event Log Entries के रूप में हम किस Information को Generate करना चाहते हैं।

इस बात को निश्चित करने के लिए कि हमारे Application के Termination से सम्बंधित Effective Information कोEvent Log Track कर रहा है अथवा उसे Customized तरीके से Handle कर रहा है या नहीं, हम हमारे Web Application में निम्न Code लिख सकते हैं:

publicstaticclassHttpApplicationExtensions
    {
publicstaticvoid TrackAppShutdown(thisHttpApplication theApp)
        {
// Use reflection to grab the current instance of the HttpRuntime object
var runtime = typeof(HttpRuntime).InvokeMember(
					"_theRuntime", 
					BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField, 
					null, 
					null, 
					null
				);

if (runtime == null) return;
// Use reflection to grab the current value of an internal property explaining 
			  //the reason for the application shutdown
var messageShutdown = 
					runtime.GetType().InvokeMember(
						"_shutDownMessage", 
						BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField, 
						null, 
						runtime, 
						null
					);

// Log an entry in the event viewer (or elsewhere ...)
if (!EventLog.SourceExists("YourApp"))
EventLog.CreateEventSource("YourApp", "Application");

var log = newEventLog { Source = "YourApp" };
            log.WriteEntry(messageShutdown, EventLogEntryType.Error);
        }
    }

इस Method को एक HttpApplication Object के लिए Extension Method की तरह Write करके इस Method को आसानी से Global.asax File में Application_End() Event Handler के अन्तर्गत Invoke किया जा सकता है। जैसे:

void Application_End(object sender, EventArgs e)
{
    this.TrackAppShutdown();
}

इस Event Handler के Execute होने के परिणामस्वरूप हमारे Application के प्रत्येक Restart के साथ ही Application Log में एक Entry हो जाती है। इसलिए इस Extension Method को हम हमारे किसी भी Web Application में उपयोग में ले सकते हैं व अपने Application से सम्बंधित Worker Process Recycling से सम्बंधित Issues के बारे में जरूरी जानकारी प्राप्त कर सकते हैं।

Extension Method, C# की एक बहुत ही महत्वपूर्ण व्‍यवस्था है, जिसका प्रयोग करके हम काफी आसानी से किसी Particular Method की Capabilities को Improve कर सकते हैं, जिसके लिए हमें पूरी Class को Inherit करने की जरूरत नहीं होती। यदि आप Extension Method के बारे में ठीक से नहीं जानते, तो उपरोक्त Method की कार्य प्रणाली आपको ठीक से समझ में नहीं आएगी।

C# के ऐसे ही और भी बहुत से Special Features हैं, जिन्हें अच्छी तरह से समझने के लिए आप हमारी अन्‍य पुस्तक “C#.NET in Hindi” पढ सकते हैं।

Configuring IIS – Output Caching Settings

ASP.NET में Output Caching पूरी  तरह से IIS 7 Web Server का Feature है। Output Caching एक ऐसी प्रक्रिया है, जिसका प्रयोग अपने Web Application की Performance को Improve करते हुए User को Web Server के माध्‍यम से Semi-Dynamic Contents Serve करने के लिए Develop किया गया है।

Semi-Dynamic Content वह Content होता है जो Request-by-Request काफी कम यानी Partially Change होता है। ये एक प्रकार से Static Content जैसे कि JPEG Images या HTML Pages के Opposite प्रकार का Content होता है और Classic ASP.NET Pages की तुलना में काफी अलग होता है, जिसे प्रत्येक Request के साथ ही पूरी तरह से Regenerate करना होता है।

पूरे Output Caching का मुख्‍य उद्देश्‍य ASP.NET Pages की Processing में लगने वाले कुछ Seconds की बचत करना मात्र होता है। क्योंकि प्रत्येक Interval के लिए सामान्‍यत: पहली Request द्वारा Serve होने वाले Page को ही IIS Web Server द्वारा Cache करके रख लिया जाता है, ताकि यदि Web Server पर फिर से Same Request Perform हो, तो उस Request की Processing न की जाए, बल्कि उस Request को Fulfill करने के लिए Cached Page को ही Response के रूप में Web Browser को Static Content की तरह Send कर दिया जाए।

लेकिन जब Interval Expire हो जाता है, तो फिर से First Request द्वारा Generate होने वाले Page को Cache कर लिया जाता है और उपरोक्त प्रक्रिया फिर से Follow हो जाती है  तथा  यही क्रम लगातार चलता रहता है।

जब IIS में Output Caching को Configure करने की बात आती है, तो सबसे पहले हमें हमारे उस Page Extension जैसे कि.aspx को Define करना होता है, जिसे हम Cache करना चाहते हैं और फिर हमें User-Mode या Kernel-Mode Caching में से किसी एक का चुनाव करना होता है।

इन दोनों प्रकार की Caching में मुख्‍य अन्तर इस बात का होता है कि Cache होने वाला Data कहां पर Store होगा। यदि हम User-Mode Cachingको Select करते हैं, तो Cache होने वाला सारा Content IIS Worker Process की Memory में Store होता है। जबकि यदि हम Kernel-Mode Caching को Use करते हैं, तो उस स्थिति में Cache होने वाला Data http.sys में Store होता है।

Kernel Cache को Use करने पर User Cache को Use करने की तुलना में लगभग 10 गुना कम समय लगता है। साथ ही इसके Response Return करने की Performance भी User Cache की तुलना में काफी बेहतर होती है। लेकिन इसकी कुछ कमियां भी हैं।

Kernel Caching केवल उन्हीं Requests के लिए Available होती है, जहां GET का प्रयोग किया गया होता है। यानी अन्‍य शब्दों में कहें तो ASP.NET Postbacks Pages के लिए Kernel Caching सम्भव नहीं है। साथ ही वे Pages जो कि Semi-Dynamic Content पर आधारित होते हैं  तथा  जो Form Values या Query String Parameters पर आधारित होते हैं, उन्हें भी Kernel Caching Mode में Cache नहीं किया जा सकता।

Kernel Caching केवल HTTP Headers पर आधारित Responses की Multiple Copies को Support करता है। साथ ही Kernel Cache Use करने पर ASP.NET Request/Cache Performance Counters Update नहीं होते।