iFinity

Written by:
Friday, May 21, 2010 5:13 PM 

A question that I field on a regular basis is ‘what performance implications are there for switching off page extensions on my DotNetNuke site?’.   If you peek around various posts and blogs, you’ll see dire warnings from people predicting the end of your server as you know it.   The main problem people have is that, when you switch off page extensions, all of the processing for all requests on the server are routed through the ASP.NET runtime, which has to serve up not only the dynamic ASP.NET pages, but all of the static content (js files, jpg files, css files et al) as well. 

My response to people has always been : switch it on and see what happens,  if your site becomes too slow then turn it back off again.  My advice tends to be of a practical nature in this respect.  My own site has been running without extensions for years, and while it is known to have the occasional hiccup, that’s never been to do with the missing .aspx on the Urls.

However, I decided to do a little bit of comparison with a standard DNN site and one with the Url Master module installed, so I could point to some empirical data when asked this question, plus give others a jumping off point to doing their own research.  As a side benefit it would give me a baseline performance comparison between the latest Url Master and standard DNN Friendly Url Provider.

Performance Criteria

Before starting, I decided the criteria I would measure across to compare.  These would be tracked over the test run and compared with each scenario.

• Memory Usage – looking for average and peak memory usage
• Open threads – looking for peaks in open threads
• Time to first byte – measures how quickly the application can send back the request
• Time to last byte – measures how quickly the application finishes the request
• Requests per second – measures the rate at which the web server is handling requests

Scenarios

• Plain DNN 5.4 Installation
• Plain DNN 5.4 Installation with Url Master
• Plain DNN 5.4 Installation with Url Master and no page extensions

Testing Platform

The testing was done on a DotNetNuke 5.4.2 installation, with the standard skin.  The installation contains 3 portals and 98 tabs across the 3 portals.   The Installation was standard apart from the Blog and Forum modules installed, and the Url Master module where tested.

The requests were collected using Microsoft Fiddler, and was equivalent to a click on each page of the first portal, which results in approximately 162 requests to the server, across all style sheets, images, css files and actual DotNetNuke pages.

The tests were submitted to the Microsoft WCAT tool (Web Capacity Analysis Tool) using the WCAT Fiddler Extension.  These were done on a Windows 7 development machine running IIS7 in integrated pipeline mode.    WCAT was configured to act as 10 concurrent clients submitting the stored requests continually for 30 seconds.

The testing configuration was designed to test a short burst of concurrent requests on the server, not to test the absolute limits of the application or the hardware.  Probably 95% of all the DotNetNuke sites I have seen fall into the type of performance envelope I’m using.  The main principle here was testing relative changes – when swapping out the standard DNN Friendly Url Provider/ Url Rewriter, what is the change in performance?

Each scenario was tested with 6 test runs, including one where the IIS service was restarted before starting, and one where the Application Pool was recycled before starting.  This gave coverage of different scenarios and was designed to show the difference between cold starts and hot running situations.

The data were obtained using a combination of both the WCAT metrics, and using the Windows Performance Monitor, which provided information on memory usage and open threads.

The above picture shows the performance counters during a test run.

Testing Results

If I were putting a ‘media talking point’ out for this article, it would be : ‘Url Master outperforms standard DotNetNuke Rewriter’.  However, in reality the testing was probably too limited in scope to come up with such a headline.  The tests did show that the Url Master module had both better response times and throughput than the standard DotNetNuke Url Rewriter, and was comparable in memory usage.

The main purpose of the testing, however, was to test whether or not the switch to ‘wildcard mapping’ or, in other words, removing the .aspx from the Urls has any measurable performance effect.  Remember, the main issue that most people have with the routing of all requests through the ASP.NET runtime is that it will result in slower performance than serving those files through the ‘Native’ IIS static file handler.

The surprising result for me was that the ‘no page extension’ scenario actually processed requests faster than when the .aspx extension was mapped to the asp.net runtime.  This is probably due to the fact that IIS7 in integrated pipeline manages this situation very well, and the extra speed can just be put down to random differences in the samples.  A more safe statement would be that no discernible effect could be found.

Requests per Second

Requests per second measures the amount of requests the web server is handling, and is a measure of throughput of the server.

As you can see from the data, the Url Master module changes the amount of requests per second that the installation can handle.  In this graph, a larger value is better. This is likely due to the level of caching used in the design.  The Url Master module caches both the index of pages for Url Rewriting purposes, and it also caches the list of Urls used when generating Urls for the output Html of a DNN page.  Thus most of the usage of the module works from in-memory caches, and restricts the amount of calls to the database.

Average time to first byte

The Average time to first byte metric shows the responsiveness of the web application to requests.  It measures the time taken before the request is submitted to the server, to when the request is received.   Note that this testing took place on the same server as the web application, so there is no network latency involved.  What we are measuring is the time taken to process the page and respond to the request.

This metric shows that the Url Master improves the response time of the DotNetNuke application in the tests run.  Again, my guess is that the way the module rewrites the rules is faster than the standard DotNetNuke Friendly Url Provider, again probably because of the caching.

Full Data Set

Below is the full dataset of the results of the tests run.   You can peruse the information and see where the differences show up. 

Conclusions

There are two main conclusions I found from this testing:

1. In IIS7 integrated pipeline, running with no page extensions makes showed no measurable difference in performance
2. The Url Master module showed better performance than the standard DotNetNuke Url Rewriter/Friendly Url Provider

These are interesting results for me, and I may expand this testing to cover different scenarios such as an IIS6 server, or to greatly increase the sample size of the requests (I’m sure a statistician would scoff at my sample size of 7).  However, they are pleasing for me as I do spend a lot of time performance optimising code and figuring out ways to make it run faster, given that the Url Master code runs every single time a page is requested in DotNetNuke.

If you see an obvious error, or repeat this testing and find a different result, please let me know via the comments.

Trackback Print

Tags:

Categories:

Location: Blogs Crafty Code

Your name:
Your email:
	(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Add Comment   Cancel