Alik Levin's

Clarity, Technology, and Solving Problems | PracticeThis.com

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

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

  • Comments 7

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

  • I think disabling viewstate is the main reason.

    Also it is possible to disable:

    validateRequest="false" enableEventValidation="false"

    and set compilation debug to false

  • 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.

  • agree regarding security points, however

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

    and it is "true" by default

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

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

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

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

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

Page 1 of 1 (7 items)