Archive
Monthly
Go
|
|
DNN Blog
Dec
7
Posted by:
Charles Nurse
12/7/2006
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.
| |
4.3.5 |
4.4.0 |
Delta |
| Total Requests |
37155 |
52836 |
+ 30 % |
| Requests / sec (average) |
20.6 |
29.4 |
+ 30 % |
| |
|
|
|
| Working Set (Average of 1-20) |
13.6 MB |
11.7 MB |
- 22 % |
| Working Set (Average of 11-20) |
9.6 MB |
7.7 MB |
- 22 % |
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.
- We have tweaked a number of stored procedures and views to remove the expensive join on "fileId=".
- 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.
- 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.
15 comment(s) so far...
Re: Performance Update - Part 2
Great article, really looking forward to release. A few questions:
1. I am researching the best hardware and Windows/IIS config for a webserver hosting multiple DNN sites. In Shaun's blog he said "2GB of available memory ... is the maximum which Windows 2003 will allocate to all user processes by default". My webserver will be running IIS 6.0 and standard 32 bit Windows 2003 only. Does this mean that it is pointless installing more than 3GB of memory in the server (1GB being ample for Windows and 2GB for user processes)? Or can the default be exceeded?
2. Did you consider creating an option to persist the PageState on disk (or even in the database)? It would be slower than in memory, but maybe a good option for high volume sites.
By lneville on
12/8/2006
|
Re: Performance Update - Part 2
Well there appears to be some debate on the answer to (1). I have read that the limit is 2GB of user memory (unless you use the /3GB switch in boot.ini which increases the amount to 3GB - remember 32-bit windows can only address 4GB. However, shaun received a comment from somebody that claimed the limit was 2GB per process. There is a way to increase the memory available and that is to switch to 64-bit windows and 64-bit processors. We have not done any testing there.
With regard to (2), I have tried to develop a disk-based persistence but have had trouble ensuring that the "key" used to identify the viewstate is correctly persisted in the page. If we are able to resolve the issues then we will add that capability.
By cnurse on
12/8/2006
|
Re: Performance Update - Part 2
I am very interested in the technical details of how you're persisting the PageState in the cache instead of in hidden variables; how do you keep track of the client session, through guid cookies?
By mattchristenson on
12/8/2006
|
Re: Performance Update - Part 2
This is some real impressive and detailed work. I think that you have understated the "improvement" you have made in the requests and requests per sec. Improvement in requests = (52836-37155)/37155 *100 = 42.2% (req/sec=42.72%) While you have overstated by a little the working set improvements... (11.7-13.6)/13.6*100 = 14% (2nd one is 19.8%) - just a detail.....
By vanram on
12/8/2006
|
Re: Performance Update - Part 2
I read your post. me too use blowery.Web.HttpCompress.dll and NFission.Web.ViewRestate.dll class library with a simple white space technic for my dnn test. it to cause better performance but I think it will efective for many request but in a simple site it hasn't more better performance. what is your idea?
By farsica on
12/8/2006
|
Re: Performance Update - Part 2
vanram - oops divided by the wrong number
By cnurse on
12/11/2006
|
Re: Performance Update - Part 2
Does these performance improvements resolve the frequent application restarts in DNN4x? I get these application every few minutes with little loading on the site. Just me adding pages, add module onto new page, config module title, etc.
By ecktwo on
12/11/2006
|
Re: Performance Update - Part 2
ecktwo - not explicitly.
I am not sure what is cauasing your frequent Application Starts, but in addition to load you will get an appstart if there are file and fodler changes on the site, as ASP.NET determines whether a recompile is neccessary.
By cnurse on
12/12/2006
|
Re: Performance Update - Part 2
this is a bit off topic but still relevant to the 4.4 Performance Release. with the popularity of javascript and ajax you should probably change the xmlconformance from "legacy" and maybe create and css based div tagged skin.
By afromobile on
12/13/2006
|
Re: Performance Update - Part 2
Ecktwo, in regards to your frequent application restarts, there is a known bug in IIS that can cause this, full details in this post (esp look at my last post):
http://www.dotnetnuke.com/Community/ForumsDotNetNuke/tabid/795/forumid/118/threadid/71023/scope/posts/Default.aspx
Charles what would be good would be to log the cause of the app restarts in detail in the site log (at the moment it's not really happening). I wouldn't be suprised if people are suffering from this issue but don't know the actual cause, see here
http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=4384
and here:
http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=4565
Thanks for upcoming 4.4 release.. looking forward to it.
Alex
By NukeAlexS on
12/17/2006
|
Re: Performance Update - Part 2
Hi Charles, obviously this is excellent work what you're doing. However, is anything done about the cold start issue, that starting sites like mine have? They sometimes takes a full minute to load, which obviously is too much for even the most patient user! What can I do about it best (apart from increasing traffic of course)?
By psiegers on
1/3/2007
|
Re: Performance Update - Part 2
Hi Charles, i very much like the idear to save the page state on the server. But there is a problem with it. If the URL becomes to long it crashes with the following error:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Here is the complete error:
An error has occurred.
DotNetNuke.Services.Exceptions.PageLoadException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. ---> System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck) at System.IO.Path.GetFullPathInternal(String path) at System.Security.Util.StringExpressionSet.CanonicalizePath(String path, Boolean needFullPath) at System.Security.Util.StringExpressionSet.CreateListFromExpressions(String[] str, Boolean needFullPath) at System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermissionAccess access, AccessControlActions control, String[] pathListOrig, Boolean checkForDuplicates, Boolean needFullPath, Boolean copyPathList) at System.Web.InternalSecurityPermissions.PathDiscovery(String path) at System.Web.Caching.CacheDependency.Init(Boolean isPublic, String[] filenamesArg, String[] cachekeysArg, CacheDependency dependency, DateTime utcStart) at System.Web.Caching.CacheDependency..ctor(String[] filenames, String[] cachekeys, CacheDependency dependency) at DotNetNuke.Services.Cache.FileBasedCachingProvider.FBCachingProvider.Insert(String CacheKey, Object objObject, CacheDependency objDependency, DateTime AbsoluteExpiration, TimeSpan SlidingExpiration, Boolean PersistAppRestart) at DotNetNuke.Common.Utilities.DataCache.SetCache(String CacheKey, Object objObject, CacheDependency objDependency, DateTime AbsoluteExpiration, TimeSpan SlidingExpiration, Boolean PersistAppRestart) at DotNetNuke.Framework.CachePageStatePersister.Save() at System.Web.UI.Page.SavePageStateToPersistenceMedium(Object state) at System.Web.UI.Page.SaveAllState() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) --- End of inner exception stack trace ---
with kind regards,
Geurt Wisselink
By gwk000 on
1/7/2007
|
Re: Performance Update - Part 2
I am having exactly the same issue as gwk000 (Geurt Wisselink)
Any ideas how to get over it?
By Smeciak on
5/17/2007
|
Re: Performance Update - Part 2
I am having exactly the same issue as gwk000 (Geurt Wisselink)
Any ideas how to get over it?
By Smeciak on
5/17/2007
|
Re: Performance Update - Part 2
Charles, we are looking at DNN to host 400-500 websites with potential for 20 million hits a month. Are there any metrics on DNN performance that will help us get a rough idea of what type of infrastructure we will need if we use DNN for this? I know there are a number of variables that impact the infrastructure requirements, but how many sql servers are we generally talking - 1? 2? More? We are evaluating DNN vs custom solution and there are some concerns about the cost of scaling the database tier since almost all of the content is stored in the DB.
By amdMcBook1 on
6/29/2007
|
|