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

My lab domain has MS CA installed in it so I am able to issue certificates to the left and to the right. Recently I spent some time to understand why client certificates authentication does not work. More precisely the certificates dialog box was offering no client certificate to chose, as depicted below:

I first thought it is something on the client machine but after some investigation it turned out that it is IIS' part. IIS was unable to verify CRL. I was not in the mood of deploying CRL's so I decided to look into how to disable this feature. Here it is:

http://forums.iis.net/t/1100044.aspx

   Set oWeb = GetObject("IIS://localhost/W3SVC")
   oWeb.CertCheckMode = 1
   oWeb.SetInfo
   Set oWeb = Nothing

Open notepad paste the code above and save with vbs extension. Run it by double clicking it. Your IIS now do not give a damn about CRL.

NOT THE BEST OPTION FOR PRODUCTION ENVIRONMENT.

Good enough for demos.

Enjoy.

I create perf counters sets up front. That way I could start collecting and measuring proper metrics right away each time I am assigned to do detailed performance analysis.

Measuring .NET Application Performance lists important perf counters. What I really love about it is that the guide holds the list of performance counters to collect, explanation for each why collecting it, and the thresholds.

Here are the steps I take creating performance counters templates:

• Open perfmon MMC (start-> run -> perfmon -> Enter)
• Expand "Performance Logs and Alerts" node
• Right click on "Counter Logs" node and click "New Log Settings", provide some name for the new log and hit Enter.
• Add counters to measure - right from Measuring .NET Application Performance.

This is how it may look:

Next would be saving the performance sets I created as depicted. It is done easy by right clicking each and saving it as html page. The resulting html page displays ActiveX with the performance counters in the set.

To restore the performance counters-set to measure it  on another computer right click on "Counter Logs" and chose "New Log Settings From..." and point to your html file.

One pitfall though. If the performance counters settings were created for specific computer then it will fail when recreating it on another. To fix it open html setting file in Notepad, remove \\MyComputer and save the file. For example:

Before

<PARAM NAME="Counter00005.Path" VALUE="\\MyComputer\System\Context Switches/sec"/>

After

<PARAM NAME="Counter00005.Path" VALUE="\System\Context Switches/sec"/>

That means that performance counters are valid for current computer.

Enjoy