While application performance is significantly governed by the performance of your application’s underlying database, there are several factors in your application that also contribute to application performance.  The chief application performance option available is the location of the application’s View State information.

View State Storage Options for Improving Performance

HTTP is a stateless protocol and a web application must maintain the state of the application.  The Microsoft .NET Framework addresses this by maintaining the state in a “View State”.  There are several storage options for View State and what you select can impact your application’s performance.  By default, .NET applications store the View State within the page itself and send this information back and forth between the server and the client.  The View State on some pages could be larger than the amount of data itself.  For example, on some Table Report pages, the amount of the View State might be 500k while the amount of data is 250k resulting in a page size of 750k.

If browser clients are running across slower connections or if they are running on slower machines, this option may result in the perception that the application is running slowly.  Virus scan utilities further compound the problem because they scan the web page data for viruses.  The combination of larger page sizes delivered to slower machines running virus scan utilities results in a significant lag before the page is displayed to the application user.

Iron Speed Designer provides several options for storing View State information.  Each option has advantages and disadvantages and must be reviewed in detail before making an appropriate selection for your application.

View State treatment on application hosting providers (ASPs)

Many ASPs automatically re-cycle application pools to conserve memory usage.  When this happens, your application’s session variables and View State information may be lost.  You can avoid this by using database-based View State storage, albeit at the penalty of slower performance.

Related View State Topics

Page-Based View State

Session-Based View State

Cache-Based View State

File-Based View State

Database-Based View State

Changing View State Options

Page-Based View State

The Microsoft .NET Framework uses this method as the default.  This option results in larger pages sent to the client browser since the view state is embedded in the page in a hidden field.

Advantages

• Process recycling has no effect:  The view state is not affected by recycling of processes on the server including the worker process.  Memory on the server is not an issue since the view state is not being saved on the server.

Disadvantages

• Slower on the server: The view state must be encrypted before being sent to the client browser and un-encrypted when it is returned.  This slows down the application running on the server.

• Additional bandwidth required: Because the page size is larger, this requires additional bandwidth.

• Anti-virus programs have more data to scan:  If the client system is running an anti-virus program (and most systems do), the anti-virus program has to scan more data during its scan to ensure that there are no viruses on the pages retrieved by the browser.

The page option slows does the server since the view state has to be serialized and encrypted on the server, and unencrypted and de-serialized at the return trip.  The page option also takes additional bandwidth and slows down the client system since more data has to be parsed by the client browser.

One advantage of the page option is that the view state is not affected by recycling of processes on the server including the worker process.  Memory on the server is not an issue since the view state is not being saved on the server.

Session-Based View State

The View State is saved in the session for each user.  A session object is user specific and times out items when the user session times out.  This timeout can be configured by changing the timeout parameter in your application’s Web.config file.  Each session object is only accessible by the given user.  The view state is saved in serialized form in the session state and must be de-serialized when retrieved.

Advantages

• Smaller page size:  The amount of data transferred to each user is minimized since there is no View State that is sent back and forth.  The size of the page is close to the size of the actual data on the page plus any HTML to enhance the appearance.

• Faster:  Because view state data is stored on the application sever and is not encrypted or sent to the client browser, this option results in the application running faster.

Disadvantages

• Missing data: Occasionally when users return back to a page after a long time and try to make further changes to the page like filtering by another value, they may see the new page with some data missing on the page.  This is the result of the session expiring or being replaced with newer session data since there may not be sufficient memory to store all of the view state data for all sessions.  In this case, you can increase the memory, increase the timeout or change the view state location to Page.  Alternatively, use the Cache option and set the timeout to be file or event based.

• Requires more memory:  Since session data is stored in memory, your server requires additional memory to store all of the session data.  When there is insufficient memory, the oldest session data is discarded in favor of the newer session data.  This may result in View State not being available when the end user returns to the page.

• Application recycling loses session state:  If your application is recycled either by modifying its Web.config file, changing the DLLs or by recycling the process, the view state data stored in the session will be discarded.  When an end user returns to the page expecting the view state to be available, they may encounter unexpected behavior.

• Windows 2003: Microsoft IIS running under Microsoft Windows 2003 allows configuration options to recycle the ASP.NET worker process based on a variety of criteria such as memory usage or based on time elapsed since the last recycle.

• Hosting: If you are hosting your application at a hosting site, you may not be able to control how much memory is allocated to your application.  You may not be able to control the frequency with which the worker process is recycled.

Managing .NET Session Data

.NET session data itself can be managed in three different ways:

• InProc (default) - Stored in the ASP.NET Worker Process (aspnet_wp.exe) area. The session data is lost when the process or the application domain is recycled as explained above.

• StateServer - Session state is stored in a separate process (aspnet_state.exe) which can be stored on a different system. Since it can be stored on a different system, this option can also work in a web farm scenario.   The View State data must be serialized since the data storage is outside the process.  Slower than InProc since data retrieval and saving requires more time.

• SQLServer - Session state is stored in a SQL Server database. This option will also work in a web farm scenario.  The View State data must be serialized since the data storage is outside the process.  Slowest option of all three since the database overhead is added to storage and retrieval times.  This is the same as option 5 of storing the session data in a database.

Modify the sessionState key in your application’s Web.config file to choose between InProc, StateServer or SQLServer.

Cache-Based View State

This option is similar to the Session option in that the view state is saved in the cache on the application server.  The advantages and disadvantages are almost the same as well.  One additional advantage of the cache option is that you can have more control over when view state data expires.  The following choices are available for cache expiration:

• Key dependency:  Items in the application cache are stored in key/value pairs.  Key dependency allows an item to be dependent on the key of another item in the application cache.  When the original item is removed, the item that has the key dependency is also removed.  For example, you could add a cache item named ReportsValid and then cache several reports that are dependent on the ReportsValid key.  When the ReportsValid item is removed, all dependent cached reports are likewise removed from the cache.

• File dependency:  An item in the cache is dependent on an external file.  If the file is modified or deleted, the cached item is removed.

• SQL dependency:  An item in the cache is dependent on changes in a table in a Microsoft SQL Server 2005, SQL Server 2000, or SQL Server 7.0 database.  For Microsoft SQL Server 2005, an item can be dependent on a row in a table.  For more information, search for Caching in ASP.NET with the SqlCacheDependency Class on the Web.

• Aggregate dependency:  An item in the cache is dependent on multiple elements through the use of the AggregateCacheDependency class.  If any dependency changes, the item is removed from the cache.

• Custom dependency:  An item in the cache is configured with a dependency that you create in your own code.  For example, you can create a custom Web service cache dependency that removes data from the cache when a call to a Web service results in a particular value.

File-Based View State

The View State is saved in a temporary file.

Database-Based View State

This option is the same as Session with the Session State saved in Microsoft SQL Server.

Changing View State Options

You can specify which option to use at an application level in your application’s Web.config file.  You can also override the application level choice for one or more pages by overriding the GetViewStateLocation() function at the page class.

To change view state options for an application, modify your application’s Web.config to define one of the following keys in the appSettings section.

<appSettings>

     <!-- only use one of the following lines -->

     <add key="ViewStateLocation" value="Page" />

     <add key="ViewStateLocation" value="File" />

     <add key="ViewStateLocation" value="Cache" />

     <add key="ViewStateLocation" value="Session" />

</appSettings>

Changing the Database View State

To change the database view state:

<add key="ViewStateLocation" value="Session" />

<sessionstate

     mode="sqlserver"

     cookieless="false"

     timeout="20"

     sqlconnectionstring="data source=MySqlServer;

          user id=ASPState;

          password=1Gr8State"

          server="127.0.0.1"

          port="42424"

/>

Overriding the View State Location for a Specific Page

To override the view state location for a specific page, add the following function to the page class:

Protected Overrides Function GetViewStateLocation() As ViewStateLocation

     ‘ Only use one of the following lines

     Return ViewStateLocation.Page

     Return ViewStateLocation.Cache

     Return ViewStateLocation.Session

     Return ViewStateLocation.File

End Function

Further Reading

ASP.NET Caching Overview:

http://msdn2.microsoft.com/en-us/library/ms178597.aspx