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 iFastrack's performance. By default, iFastrack stores the View State within the page itself and sends 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 List 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 user.

iFastrack 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. iFastrack 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.