Viewstate Optimization Strategies in ASP.NET (2/3)

[previous] [next]

Viewstate Optimization Strategies in ASP.NET

Scenario 1: Network bandwidth is the constraint

This is the typical scenario of a Web site on the Internet, e.g. an e-commerce site. While it is easy to assign more hardware to alleviate performance issues, there is little that can be done about network bandwidth at the client side. Generally, pages should be made as light as possible. A highly interactive page with server side controls belonging to the heavy control group will add a lot of viewstate data, increasing the size of the page considerably. This viewstate not only needs to be downloaded by the client but also uploaded during post back. Thus, a 1 Kb increase in viewstate increases the traffic by 2 Kb.

Thus, our strategy's main aim should be to minimize viewstate data.

The DataGrid control is a particularly heavy viewstate user. By default, all of the data displayed in the grid is also stored in viewstate, and this is particularly useful when an expensive operation (like a complex SQL query) is required to fetch the data. However, this behavior also makes DataGrid the prime suspect for unnecessary viewstate. If sorting and paging is being used then a rebind of the DataGrid to its dataview class is necessary on every post back and the entire viewstate of the DataGrid is unnecessary. Even when sorting and paging is not being used the grid should be rebound on every post back. If this rebinding requires a complex query then it is worthwhile to investigate whether the query can be broken into expensive and not so expensive operations. If this can be done then only the results of the expensive operations need be stored in the viewstate and reused on every post back to rebind the grid.

Sometimes data can be added to the viewstate judiciously for overall benefit. The most striking example is provided by Web farms. Typically, in these scenarios the session state is persisted in an external database since a session may jump between servers during its lifetime. In this case, the session data is fetched from the database, deserialized and made available to the page. Any changes to the session data that follow are serialized and persisted to the database. Although ASP.NET's session persistence makes it easy to implement this, it is an expensive process. Instead, if this data is stored in viewstate then the roundtrip access to the database can be completely eliminated. While adding data to the viewstate, keep in mind that viewstate is optimized to work with the following types:

• int, boolean, string, and other primitive types {both boxed and unboxed versions}
• arrays of primitive types
• ArrayList and Hashtable
• Any type that is marked with the serializable attribute, or supports the serializable interface

The above should allow the ability to store most data structures into viewstate. Once again, there is a critical amount of data when it becomes more efficient to store it in the database. This will depend on the individual characteristics of the application setup and can only be found empirically.

The are two caveats that should be kept in mind when persisting data in viewstate. First, viewstate data is easy to decode (since it is basically base64 coding). Thus, any sensitive information (e.g. credit card numbers) should not be stored in viewstate and sent over an insecure link. Sensitive information can be stored in the viewstate if it is encrypted and hashed as described later. Second, sessions, unlike viewstate, time out after a predetermined time. If timeout functionality is required then sessions must be used instead of viewstate to store data.

[previous] [next]

Created: November 20, 2002
Revised: November 20, 2002

URL: https://webreference.com/programming/asp/viewstate/2.html