Performance Update - Part 2

In an earlier Blog I provided an introduction into the Performance Enhancements we have implemented for 4.4.0.  I also mentioned that we had been able to spend a week in the Microsoft Patterns and Practices Test Lab, carrying out some performance tests.

In this Blog, I am going to describe the "top-level" performance metrics we were able to measure. The results I am going to describe were carried out by creating two similar test-beds, one configured with the 4.3.5 Release, the other with the 4.4.0 interim development code.  500 identical sites were created on the Webserver (simulating a hosting environment) distributed between 5 Application Pools. 

The test was as follows.  A simple simulation script that browsed a few pages was created and using the Visual Studio Team Suite tools it was modified so that each time the script was run it browsed to a different instance of dotnetnuke.  Thus over time the number of applications running would increase. Shaun has blogged that once loaded an Application stays in memory until the Application Pool recycles.

Below is a summary of the results for a 30 minute run.

 So the new code improves the "preformance" of a site by ~30%, and reduces the memory footprint by ~20%. 

It should be noted that this was an idealised situation - ie only the basic modules were installed required to provide simple static pages, and extensive use of custom 3rd party modules will impact the total number.  However, we were concerned with improving the performance of the core framework and these numbers confirm that we have indeed improved that.

Shaun and I have both blogged about the kind of things that we have inclued in this upcoming release to improve performance.  These tests do not include all the enhancements as there has been more development in the last few weeks since my return from Redmond.

There are 3 major enhancements that are not included in these tests.

1. We have tweaked a number of stored procedures and views to remove the expensive join on "fileId=".
2. We have added the ability to persist the PageState (ViewState and ControlState) on the server in the cache.  This reduces the payload of a typical page by 10-15% which should reduce response time (it does however add to the Working Set as the Page State is now saved in the Server-side cache)  - what you gain in speed you might lose in scalability.
3. We have incorporated the Blowery Compression Module into the core package, and included a simple Whitespace Filter.  The compression module itself can reduce the payload of a page request by 50-75%, but it impacts server performance considerably, so it needs to be used wisely in a shared hosting environment.  The whitespace filter will reduce the payload by 10-15%, but has very little impact on server performance.

Stay tuned for further updates as we roll out this important release.