Thursday 18 October 2012

How can cache different version of same page using ASP.NET cache object ?

Output cache functionality is achieved by using “OutputCache” attribute on ASP.NET page header. Below is the syntax

<%@ OutputCache Duration="20" Location="Server" VaryByParam="state" VaryByCustom="minorversion" VaryByHeader="Accept-Language"%>




  • VaryByParam :- Caches different version depending on input parameters send through HTTP POST/GET.

  • VaryByHeader:- Caches different version depending on the contents of the page header.

  • VaryByCustom:-Lets you customize the way the cache handles page variations by declaring the attribute and overriding the GetVaryByCustomString handler.

  • VaryByControl:-Caches different versions of a user control based on the value of properties of ASP objects in the control.


How will implement Page Fragment Caching ?


Page fragment caching involves the caching of a fragment of the page, rather than the entire page. When portions of the page are need to be dynamically created for each user request this is best method as compared to page caching. You can wrap Web Forms user control and cache the control so that these portions of the page don’t need to be recreated each time.

Can we compare ASP.NET sessions with classic ASP?


ASP.NET session caches per user session state. It basically uses “HttpSessionState” class.

Following are the limitations in classic ASP sessions :-

  • ASP session state is dependent on IIS process very heavily. So if IIS restarts ASP session variables are also recycled.ASP.NET session can be independent of the hosting environment thus ASP.NET session can maintained even if IIS reboots.

  • ASP session state has no inherent solution to work with Web Farms.ASP.NET session can be stored in state server and SQL SERVER which can support multiple server.

  • ASP session only functions when browser supports cookies.ASP.NET session can be used with browser side cookies or independent of it.


Which various modes of storing ASP.NET session ?



  • InProc:- In this mode Session state is stored in the memory space of the Aspnet_wp.exe process. This is the default setting. If the IIS reboots or web application restarts then session state is lost.

  • StateServer:- In this mode Session state is serialized and stored in a separate process (Aspnet_state.exe); therefore, the state can be stored on a separate computer(a state server).

  • SQL SERVER:- In this mode Session state is serialized and stored in a SQL Server database.


Session state can be specified in <sessionState> element of application configuration file. Using State Server and SQL SERVER session state can be shared across web farms but note this comes at speed cost as ASP.NET needs to serialize and deserialize data over network again and again.

Is Session_End event supported in all session modes ?


Session_End event occurs only in “Inproc mode”.”State Server” and “SQL SERVER” do not have Session_End event.

What are the precautions you will take in order that StateServer Mode work properly ?


Following are the things to remember so that StateServer Mode works properly :-

  • StateServer mode session data is stored in a different process so you must ensure that your objects are serializable.

  • <machineKey> elements in Web.config should be identical across all servers.So this ensures that encryption format is same across all computers.

  • IIS metabase (\LM\W3SVC\2) must be identical across all servers in that farm.

No comments:

Post a Comment