ASP.NET 2.0 Performance Guidelines - View State

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, John Allen, and Alex Mackman


If You Do Not Need View State, Disable It

View state is turned on in ASP.NET by default, disable view state if you do not need it.


Why

View state is an unnecessary overhead for pages that do not need it. As the view state grows larger, it affects performance in the following ways:

  • Increased CPU cycles are required to serialize and to deserialize the view state.
  • Pages take longer to download because they are larger.
  • A large view state can impact efficiency of garbage collection.


When

You can disable views state when the following conditions are true:

  • Your page does not post back. If the page does not post information back to itself, if the page is only used for output, and if the page does not rely on response processing, you do not need view state.
  • You do not handle server control events. If your server controls do not handle events, and if your server controls have no dynamic or data bound property values, or they are set in code on every request, you do not need view state.
  • You repopulate controls with every page refresh. If you ignore old data, and if you repopulate the server control each time the page is refreshed, you do not need view state.


How

There are several ways to disable view state at various levels. To ensure that the ViewState has been disabled for the controls / pages / applications that don't require it, use the following steps:

Identify server controls on page that do not handle events, have no dynamic or data bound values, are set for every request, these controls don't require view state. Disable view state for these controls by setting the EnableViewState property of the control to false, as shown in the following code fragment.

yourControl.EnableViewState = false;

Or

<asp:datagrid EnableViewState="false" runat= "server" />

Identify pages that do not post back and all server controls on the page that don't require view state, these pages don't require view state. Disable view state for these pages by using the @ Page directive as follows.

<%@ Page EnableViewState="false" %>

Identify if a particular application on the web server has all static pages or its pages don't require view state, this application then don't require view state. Disable view state for this application by configuring the <pages> element in the Web.config file as follows.

<system.web>
   ...
  <pages enableViewState="false"/>
  ...
</system.web>

If all the applications on a web server don't need view state, disable view state for all applications by configuring the <pages> element in the Machine.config file as follows.

<system.web>
  ...
  <pages enableViewState="false" />
  ...
</system.web>


Problem Example

An ASP.NET application is composed entirely of static pages. Unfortunately, it enables view state resulting in unnecessary overhead which has a negative impact on application performance.

<system.web>
  ...
  <pages enableViewState="true" />
  ...
</system.web>


Solution Example

An ASP.NET application is composed entirely of static pages. The view state for the static web site is disabled by configuring the Web.config file. This setting allows the application to avoid unnecessary processing overhead associated with view state.

<system.web>
   ...
  <pages enableViewState="false"/>
  ...
</system.web>


References


Minimize the Number of Objects You Store In View State

Minimize the number of objects you store in view state


Why

As you increase the number of objects you store in view state, the processing time required to serialize and deserialize the objects increases. A large ViewState also increases bandwidth requirements of your application as the data is sent back and forth to the server.


When

This is important guideline and should be followed at all times when using ViewState in a performance sensitive application.


How

Analyze the code and determine the number of objects that are being stored in ViewState, there are two options available for reducing the number of objects in ViewState:

Store the data in alternative location The best and most commonly used alternative to ViewState is storing the data in session state. Pay particular attention to the following types of objects: Large Objects. The size of the object is directly proportional to the size of the view state. This in turn increases the size the page sent to the browser and the size of form posted back. This makes ViewState a bad choice for storing large size data. Sensitive data which is not be displayed in the UI. If the data is sensitive and need not be displayed on the UI storing it in session state better option as it is not sent to the client. Storing non-basic types, for example, DataSet. View state is optimized for serializing basic types such as strings, integers, and Booleans, and objects such as arrays, ArrayLists, and Hashtables if they contain these basic types. When you want to store another type, ASP.NET internally tries to use the associated type converter. If it cannot find one, it uses the relatively expensive binary serializer.

// storing large data in session state instead of view state
...
// ViewState["LargeDataObject"] = value;
Session["LargeDataObject"] = value;
...

Reduce the number of objects For example, rather than a two-dimensional string array of names/values (which has as many objects as the length of the array), use two string arrays (only two objects). However, there is usually no performance benefit to convert between two known types before storing them in ViewState - then you're basically paying the conversion price twice.


Problem Example

An ASP.NET application has a large number of server controls which by default store their state in the ViewState. Additionally the page computes a large data object and stores it in ViewState as for later use. Placing large data objects in ViewState decreases application performance due to increased serialization and bandwidth costs.

...
// LargeDataObject property is tracked in ViewState
object LargeDataObject
{
  get 
  {
     return ViewState["LargeDataObject"];                       
  }
  set 
  {
     ViewState["LargeDataObject"] = value;
  }
}

private void btnTest_Click(object sender, System.EventArgs e)
{
  // do some processing for computing the big data object
  LargeDataObject = BigObject;
}
...


Solution Example

An ASP.NET application has many server controls which stores their state in the ViewState, the page computes a large data object and stores it in session state instead of ViewState as the data is required for later use. Storing the large object in session state rather than ViewState improves overall performance of the application due to the fact that the object doesn't see client/server roundtrips.

...
// LargeDataObject property is tracked in session state
object LargeDataObject
{
  get 
  {
     return Session["LargeDataObject"];                       
  }

  set 
  {
     Session["LargeDataObject"] = value;
  }
}

private void btnTest_Click(object sender, System.EventArgs e)
{
  // do some processing for computing the big data object
  LargeDataObject = BigObject;
}
...

Also disabling ViewState for the controls that don't need it by setting the EnableViewState property of the control to false, as shown in the following code fragment. This improves the performance of the application.

<asp:datagrid EnableViewState="false" runat= "server" />


References


Use Tracing to Analyze and Reduce the Size of Your View State

Enable tracing for the page, and monitor the view state size for each control. The view state size for each control appears in the rightmost column in the control tree section of the trace output. Use this information as a guide to determine if there are any controls for which you can reduce the amount of view state or if there are controls that don't need viewstate at all.


Why

Reducing the size of ViewState improves performance of the application as follows:

Decreases CPU cycles required to serialize and to deserialize the view state. Pages are downloaded fast because as the HTML payload is smaller. Tracing and analyzing the ViewState information helps you to determine the controls and objects that are most responsble for a large ViewState.


When

This is important guideline and should be followed whenever using ViewState in a performance sensitive application.


How

Use the following steps to analyze and reduce the size of ViewState:

Enable Tracing on the Page. Determine the pages which use ViewState and enable tracing by setting the Trace Attribute of the Page element to True. Please note this should be done in development environment only, when deploying ensure the tracing is disabled for all the pages. Tracing has adverse impact on performance of the application.

<%@ Page Language="C#" Trace="True" ...>

Analyze the ViewState size on the page request When you request a page or post back the page you will be able to see trace info at the end of the page. In the Trace details go to the Control Tree section and view the ViewState size in Bytes. Analyze the controls with ViewState and determine if they require the ViewState, if they don't disable the ViewState for the controls as follows.

yourControl.EnableViewState = false;

Or

<asp:datagrid EnableViewState="false" runat= "server" />

Analyze the controls with larger ViewState and determine if any of the data can be moved to session state. The most common reasons for moving data to session state is: Large Data Objects Sensitive data which is not be displayed in the UI Non-basic types, for example, DataSet


Problem Example

An ASP.NET application has a large number of server controls which by default store their state in the ViewState. Additionally the page computes a large data object and stores it in ViewState as for later use. Placing large data objects in ViewState decreases application performance due to increased serialization and bandwidth costs.

...
// LargeDataObject property is tracked in ViewState
object LargeDataObject
{
  get 
  {
     return ViewState["LargeDataObject"];                       
  }
  set 
  {
     ViewState["LargeDataObject"] = value;
  }
}

private void btnTest_Click(object sender, System.EventArgs e)
{
  // do some processing for computing the big data object
  LargeDataObject = BigObject;
}
...


Solution Example

An ASP.NET application has many server controls which stores their state in the ViewState, the page computes a large data object and stores it in session state instead of ViewState as the data is required for later use. Storing the large object in session state rather than ViewState improves overall performance of the application due to the fact that the object doesn't see client/server roundtrips.

...
// LargeDataObject property is tracked in session state
object LargeDataObject
{
  get 
  {
     return Session["LargeDataObject"];                       
  }
  set 
  {
     Session["LargeDataObject"] = value;
  }
}

private void btnTest_Click(object sender, System.EventArgs e)
{
  // do some processing for computing the big data object
  LargeDataObject = BigObject;
}
...


References

Personal tools