Improve ASP.NET Performance By Disabling ViewState And Setting Session As ReadOnly

During recent engagement we tried to improve performance of some web page. Original response time was 0.74 seconds. Our objective was to get 0.4 seconds.

The page was simple Html Frameset that was loading two dynamic ASPX pages. Using technique described in Performance Testing For The Masses we identified that it takes 0.4  seconds for one page and 0.2 seconds for another to run on the server (we used time-taken property of the IIS log).

Reviewing the code revealed that there is usage of server controls and both pages read from the Session object.

The assumption was that since no user input is done we can disable ViewState saving on CPU to build the ViewState.

The other assumption was that since the Session is accessed for read only then we can set it as read only saving on locking and preventing race conditions.

This is how each page's header looked after the change:

<%@ Page EnableViewState=”false” EnableSessionState=”ReadOnly” ...%>

Simple change for ASP.NET mark up, no rebuild required.

After running load test for this new version of ASPX page response time was 0.35 seconds.

Another metric was ASP.NET\ Request Execution Time performance counter that dropped from 0.7 seconds to 0.3 seconds.

Sweet.

Source of performance wisdom is here Improving .NET Application Performance and Scalability

Enjoy

Published 16 August 07 02:44 by alikl

Comments

# Anatoly Lubarsky said on August 16, 2007 10:15 PM:

I think disabling viewstate is the main reason.

Also it is possible to disable:

validateRequest="false" enableEventValidation="false"

and set compilation debug to false

# alikl said on August 16, 2007 11:45 PM:

Generally speaking I think you are right w/r to viewstate – to support your point the mentioned perf counter dropped significantly. Reading Session data is not CPU consuming but may cause race conditions and as a result serialization of execution.

Disabling validateRequest is not the best option from security perspective since it helsp preventing potentially malicious input getting into the system. Must mention it is far from being perfect solution for input validation though http://www.procheckup.com/Vulner_PR0703.php

Good point w/r to enableEventValidation. Specifically with my case it was Net Fx 1.1 and the attribute was introduced in Net FX 2.0.

From security perspective it is not recommended disabling enableEventValidation.

# Anatoly Lubarsky said on August 17, 2007 11:32 AM:

agree regarding security points, however

setting compilation debug "false" proved to be efficient especially in .net 2.0

and it is "true" by default

# alikl said on August 18, 2007 4:03 AM:

w/r to debug "The default is False."

http://msdn2.microsoft.com/en-us/library/s10awwz0.aspx

# alik levin's said on January 2, 2008 5:38 AM:

During recent few engagements with my customers I've noticed&#160; VIewState is extensively [unintentionally]

# Noticias externas said on January 2, 2008 5:45 AM:

During recent few engagements with my customers I&#39;ve noticed&#160; VIewState is extensively [unintentionally

# alik levin's said on January 21, 2008 4:37 PM:

Care about performance? Do you write your code with performance in mind? Want little help to spot performance

New Comments to this post are disabled

Search

This Blog

. My Personal Blog .

.Net Performance How To's

.Net Security How To's

Design Patterns

Impactful

Lifecycle Phases

Popular

Tools

Syndication

Page view tracker