Recently, Keivan Beigi posted an article on the DNN Blog about how DotNetNuke 5.5 was faster than DotNetNuke 4.9.5. This post generated a flurry of emails to my inbox wondering whether the new version of Url Master compared to this. I have already posted about the relative performance of Url Master and the standard DotNetNuke Url Rewriter which showed that the Url Master module was faster than the standard DotNetNuke Url Rewriter/Friendly Url Provider by a small margin. In that post, my aim was to determine the difference in speed with no-extensions vs .aspx extensions (conclusion : not significant) – finding out that the standard Friendly Url Provider was slower was an unexpected result.
So with the release of the faster DNN 5.5 version, at the request of many people, I’ve done some comparison testing on both DNN 5.4, 5.5 with both the standard Url Rewriter/Friendly Url Provider and the latest release of the Url Master module, which is 2.0.1.
Before we get started, just a quick note to clear up one question that has arisen. The Url Master module is designed as a complete and total replacement for the standard Url Rewriter / Friendly Url Provider (it’s one piece of code that does both things). Therefore, when you install the Url Master module and activate it, your site no longer uses the standard provider in any way. If you are currently using 5.4 (or earlier) with the Url Master module, installing 5.5 won’t yield the performance increase attributed to the upgraded 5.5 provider. That’s because your site was already running faster anyway.
Performance Testing setup
Like my previous testing, I installed a standard DotNetNuke 5.5 installation, and installed the Blog and Forum modules. The site has about 5 non-admin tabs, plus a blog post and forum thread. It’s a very lightweight DNN installation, but that’s OK because we are testing relative performance of two modules. Because it was a 5.5 install, I installed and configured the site to run two separate language packs, and used the new multi-language features of DotNetNuke 5.5. This actually means that most of the Urls on the standard installation don’t use ‘human friendly’ urls, and instead drop back to the ‘search friendly’ Urls.
The tests were a collection of 17 normal page requests, and were submitted using the WCAT for Fiddler testing tool, using 10 virtual clients over 30 seconds. The tests were all done on a single development machine, so there is no network latency involved. This represents a short burst of high traffic.
Unlike my prior testing, however, the requests were restricted only to the actual DNN pages – and don’t include any of the css,js, jpg or other files. In this respect, only the DNN Url Rewriting and page generation (which includes Friendly Url generation) is being tested.
Four scenarios were tested : one each for DNN 5.4 and 5.5 with the standard provider, while Url Master 1.15 was tested against 5.4 and Url Master 2.01 was tested against DNN 5.5. The reason for this is to show the improvements in 1.15 –> 2.01. You can assume that 2.01 with 5.4 would perform nearly identical, because the big improvement in 5.4->5.5 is from the Friendly Url generation.
The tests were repeated 6 times for each scenario, which showed remarkably little variance in results. These include two cases where the IIS server is restarted, and one where the IIS Worker Process is killed forcing a restart (and reload) of the application.
Performance Testing Results
Response Time
The first category to be examined is the Response time to First Byte. This tests how fast the Url is rewritten, the page is generated and is streamed back to the server. The measurement is in milliseconds (1000 milliseconds to a second), and there are two data points – one for average response time, and another for median response time. The median response time is that time where 50% of the responses are faster, and 50% of the responses are slower. This eliminates skewing by an abnormally large or small response time, which can have an effect on the average. The graph is shown below – smaller is better:
As you can see, there are 4 separate scenarios with the average and median results.
Results Analysis – Response Time
The first thing to notice is that Keivan’s claims to have doubled the speed from 5.4 to 5.5 certainly agreed with my results. The response-to-first-byte times have more than halved with this change.
The second thing to notice is that Url Master is no longer faster than the standard provider, which is a shame but not entirely unexpected as it does about 3x as much processing in the same function. In any case, the difference is about 60 milliseconds – 1/5th of the time it takes you to blink an eye. Most people won’t be able to notice the difference. The problem is that all the low-hanging optimization fruit in the Url Master code has been picked clean, so incremental performance is harder and harder to extract.
The last thing I’d like to point out is the improvement between the 1.15 and 2.01 versions of Url Master – while the average speed shows only a 15% increase, the median speed is nearly half. This is because the 2.x codebase of Url Master uses a much more optimised way of building the internal page index which keeps track of all the Urls in a portal. With this new optimization, a request where the page index is rebuilt (because of application recycling or a change in the Urls of the portal) completes much faster. The result is you have fewer slower loads (with 1.15, the occasional request would take 500 ms or more as the page index was rebuilt) which brings the median down lower than the average. In other words, you’re much less likely to strike the occasional slower-loading page.
Requests per Second
The next category to be checked is Requests per second. This is a measure of how fast the web server was able to process the requests. The absolute values are again unimportant here, it’s the relative differences that we’re interested in. In this case, a higher value is better because it shows the servers ability to process requests faster. It’s related to average response times – because the faster the response, the more that can be done per second.
Again you can see the results for the 4 separate tests, which shows the 4 different scenarios.
Results Analysis – Requests per second
DNN 5.5 with the Standard Url Rewriter also shows up as being the fastest solution here. Again we can see that 5.4 with the Standard Url Rewriter is the slowest, and that Url Master 1.15 –> 2.01 has seen a 15% improvement in performance. Finally, it’s apparent that the performance optimizations done on the 5.5 Friendly Url Provider / Url Rewriter have yielded a more than 2x improvement over the 5.4 codebase, so the DNN team should feel happy about that. Hopefully there are more fixes to be found in the general codebase as well.
Conclusion
So what does this all mean? Well, it means that if you use the standard Url Rewriter for any 5.x version up to 5.4, you will yield a performance improvement by moving to the 5.5 codebase. I’d advise caution for critical, live, sites, however, as there are a lot of changes in 5.5 and I’d wait a little while and be prudent to see how it shakes out as a release.
If you’re using Url Master 1.x, you’ll also see a small improvement going to the 2.01 version, regardless of what version DNN you have. You can purchase an upgrade here if you’re still on a 1.x version of Url Master.
Note that Url Master 2.01 or better is required for DotNetNuke 5.5. There are significant changes to DNN 5.5, and previous versions of Url Master won’t work. You should upgrade your Url Master module to 2.01 (or 1.16 if you haven’t upgraded) before upgrading to DNN 5.5.
With regards to the lead now yielded to the standard provider, it’s going to be difficult to whittle that down with further code optimizations, as it’s already been run through the profiler many, many times. It’s important to keep it in context though – it’s only a very small margin, and it’s because the Url Master module has so many more features in it. With DNN 5.5 now including the ability to run a Multi-Language site out-of-the-box, it’s important to remember that the standard Friendly Url Provider now drops back to the old /tabid/xx/default.aspx style Urls, and can’t use Human Friendly Urls at all with the multi-language features. With Url Master 2.01, you can have not only human-friendly Urls for your Multi-Lingual site, but you can also customise those Urls to suit the specific language. And I think that’s worth a 60 millisecond penalty.
See more on Url Master 2.x Multi-Language features in the original blog post.
Download the latest version of Url Master, compatible with DotNetNuke 5.5