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.
Page (default): The View State is sent to the client browser. Because the View State is part of the page, this guarantees that the page’s view state is always accurate. However, the resulting page sizes are large, increasing the bandwidth requirement as well as slowing the client browser since it has to parse larger and larger amounts of data. The Microsoft .NET Framework uses this option as the default.
Session: The View State is saved in the session for each user on the application server. The View State is not sent with the page to the client browser. If the session expires based on a timeout or if the ASP.NET worker process is recycled, the view state information will be lost. This option provides the best balance of performance and usability.
Cache: This option is similar to the Session option in that the view state is saved on the application server in the cache. Cached data is not associated with a specific user, so it is available to be used by any session. If security is a major concern for an application, we recommend not using the cache option. Caching allows more flexibility in terms of how long the data is stored on the server. The expiration of the data can be based on a time stamp for a file, on another cached item, or based on absolute or sliding time scale. This option should be considered when you require more control over how long to preserve the view state than is provided by storing view state in the session.
File: The View State is saved in a temporary file. This option is not recommended since writing and reading the data from a file will result in slower performance on the application server. If you select this option, you will need to periodically clean up the temporary files. This option also requires you to configure your application to have file system writing privileges.
Database: This option is similar to the File option in that it stores the information in a more permanent storage. This option will also result in slower performance on the application server. If you select this option, you will need to periodically clean up the database to remove old and expired sessions. This option avoids losing your View State information when a server’s application pool is recycled, causing session-based View State information to be lost as may be the case with many 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.
Improving Database Performance
Improving Application Performance
View State Storage Options for Improving Performance
Windows 2003 Application Performance Suggestions
Running Applications on Multiple Servers