ThreadAbortException

August 2006 Entries

ASP.NET 2.0 Performance Tuning Considerations

ASP.NET 2.0 has started picking up the momentum and alredy there are a large scale of companies using it for developing cutting edge web applications.

While the features, enhancements have been very good, the decisive factor in web applications development is performance.

ASP.NET 2.0 in general has a lot of performance enhancement feature starting from compilation model to ADO.NET 2.0 DataSets which is comparitively faster than its predecessor. Please check
New DataSet Features in ADO.NET 2.0 for more information.

Herebelow are some of the performance considerations I have observed after digging dirty with performance tuning ASP.NET 2.0 Applications.

Paging through Records
Always use Custom Paging and dont rely on the default built-in paging mechanism for GridView, DataGrid etc.,

Please check my earlier articles on custom paging

Using Cache / Session Objects

Using SQL Server

Turn off Session State
ASP.NET uses a built-in session state mechanism as well as supports your Custom Session State model. However, the cost of Session storage becomes heavy when the users, objects stored increase significantly. Turn off Session State for pages which dont require Session. Typically in a web application there may be static as well as dynamic pages. In the static pages, which dont require Session, the Session State can be turned off. Wherever, you just require Session Data as ReadOnly (where you wont be updating the Session Data), the SessionState can be made ReadOnly.

To turn off Session State at page level,

<%@ Page EnableSessionState="False" %>

To make it ReadOnly at page level,

<%@ Page EnableSessionState="ReadOnly" %>

If your Website has a lot of content pages which are static and only certain pages require Session Data, try considering Turning off SessionState at the Web.Config level and only enable it for those pages which require Session Data. Always the Page settings will override the web.config settings. Session State can be turned off in the web.config as follows:-

<pages enableSessionState="false"></pages>

Turn off View State
View State is the wonderful mechanism which stores the page as well as controls' data, state etc., across round trips. However, the View State can grow heavy significantly increasing the load and hence, View State must be turned off for pages which dont require the same. ViewState can be turned off at page level as follows:-


<%@ Page EnableViewState="False" %>


Use Caching
Cache your pages wherever possible. When implementing OutputCache, set a longer duration than setting a shorter duration. A longer duration Cache is much more better than quick short duration caches.

When the content of page can change, try using Cache with Dependency. There are various dependency techniques such as FileDependency, Database Dependency etc., to invalidate the cache.

Use IsPostBack
The IsPostBack is your best friend in controlling when to load the controls, populate data. ASP.NET, by default postbacks to the server for any/all operations and the number of Page_Loads you would be having will be significant. When using IsPostBack, it validates that the DataBinding methods are called only the first time the page loads and not for subsequent PostBacks.

if(!IsPostBack)
{
// Data Bind your Controls
}

Use DataSources
The Provider model and the DataSource controls in ASP.NET 2.0 not only simplify the Data Binding techniques but also provide significant performance enhancements by caching the Data as well as reducing the number of DB hits required to populate similar data on different controls. The Provider model eliminates the Control from the underlying Data Model thereby making it a thin layer which just represents whatever is bound to it.

When using SqlDataSource, ObjectDataSource etc., an important point to note is that, you dont need to bind the Data explicitly to the controls using DataBind.Ex.-

GridView1.DataSourceId = SqlDataSource1 // where SqlDataSource1 is the ID of the Datasource control.

That is all required. You dont require the GridView1.DataBind(); method which we are very familiar from .NET 1.0. The reason is that, the DataBind method is implicitly called by the EnsureDataBound method of the DataSource control. If we call it explicitly, then it results in a double binding of Data.

There are some other points which I will be covering in the next part of this article.

Please note that some of the points are not specific to ASP.NET 2.0 but do apply for ASP.NET 1.x versions as well. Secondly the performance considerations are mentioned assuming the implementations are done in the proper way with best practices in coding standards etc.,

Cheers and Happy Programming !!!