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

[previous]

Viewstate Optimization Strategies in ASP.NET

Scenario 2: Processing power is the constraint

This is the usual scenario of a local intranet site running over a corporate LAN. The available bandwidth is usually many times more than that over the Internet, so the constraint usually lies in server side processing power. Typically there is less hardware available for running an intranet as compared to an external facing Internet site. Intranet applications also tend to be more interactive, having very quick and frequent post backs between pages owing to the speed of the network and the nature of the application.

In such a scenario, application design should favor putting as much reusable data in the viewstate as possible minimizing database access. This is done by checking for the Page.IsPostback property in the Page_Load event of the page. Data is loaded from the database only for the initial load. All subsequent requests are served using the stored viewstate.

This strategy results in making the application servers the critical resource and not the database server. This is a favorable scenario since we can get an almost linear increase in performance by adding more application servers 'till the database becomes the critical resource. Thus, viewstates of all controls of the heavy control group that require database access to build themselves should be enabled. In this way, they need to be built only once for every page and built from the viewstate on post backs. An exception as always is DataGrid with sorting and paging allowed on it. Then it needs to be rebound on every post back and enableviewstate should be false.

There is a directive, EnableViewStateMac, that can be set to either true or false at the page level or in web.config. When true, a hash code is appended to the viewstate during page rendering. On post back the hash code is calculated again and checked with the stored value. The page is rejected if they are not the same. This ensures that the viewstate has not been tampered with during the roundtrip from the client to the server. While this feature has its uses over an insecure Internet connection it requires extra cpu resource on the server. On an intranet where there is less chance of the viewstate being tampered with EnableViewStateMac can be set to false in web.config to increase performance.

Checking viewstate size

After we implement our strategy we need to check the results. Each .aspx page developed should be tested for viewstate size before releasing to production. Server side tracing of ASP.NET pages do not allow us to see the size of the total viewstate of each page. It just displays individual viewstate sizes of the controls. Does this mean we have to laboriously open every page in the browser and see the source of the viewstate and compare sizes? No. Fortunately, there is a better way of doing things. We can create a base page class that every other .aspx page in our application inherits. This class can override the OnPreRender event of the page class to trace the viewstate. This trace can then be used to see the size of the viewstate. The code for this class is shown below.

using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Web;
using System.Web.SessionState;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;
namespace ViewState
{
  public class BasePage : System.Web.UI.Page
  {
    protected override void OnPreRender(EventArgs e)
    {
      object ViewState = HttpContext.Current.Request["__VIEWSTATE"];
      if(ViewState == null)
      {
        HttpContext.Current.Trace.Warn("ViewState Size", "0");
      }
      else
      {
        HttpContext.Current.Trace.Warn("ViewState Size", 
          HttpContext.Current.Request["__VIEWSTATE"].Length.ToString());
      }
      base.OnPreRender(e);
    }
		
  }
}

Conclusion

Viewstate of a page is affected most by the controls belonging to the heavy control group. The amount of viewstate data being stored by these controls should be carefully monitored to see whether they are within acceptable limits of the concerned application. Particularly, special care should be given to the DataGrid control. In some situations, data can be added to the viewstate instead of the session to reduce database access and increase performance.

About the Author

Utpal Chakraborty is Manager, Software Engineering at Organic (https://www.organic.com). He has extensive experience in developing enterprise applications using Microsoft and non-Microsoft technologies. He can be reached at [email protected].

[previous]

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

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