This post shares case studies of high CPU utilization of ASP.NET web sites. High CPU utilization was caused by lack of batch compilation, multiple folders, and use of XmlSerializer. In all cases the result was high CPU and poor performance; the symptom was .NET CLR Loading\Current Assemblies counter showing “unusual” number of loaded assemblies.
Customer reported a high CPU utilization during load/stress testing. After quick investigation we identified that debug attribute was configured to “true” in web.config. Here is what ASP.NET authorities have to say about configuring debug to “true” for ASP.NET web sites:
1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled) 2) Code can execute slower (since some additional debug paths are enabled) 3) Much more memory is used within the application at runtime 4) Scripts and images downloaded from the WebResources.axd handler are not cached”
There are three main differences between debug=true and debug=false:
To prevent further deployment mistakes like this one we created simple performance deployment checklist that included checking debug=”false” configuration among other checks. Following are others checks you might consider when deploying newer version of ASP.NET web site to production:
Customer reported slow response of the ASP.NET web site. After quick investigation we identified that the application’s deployment assumes multiple folders – high tens of folders. This approach took place due to team’s decision to develop every functional module as a separate folder.
ASP.NET batch compilation is the process of compiling ASP.NET markup (content of aspx files) into temporary dll’s. Compilation requires invoking compiler (csc.exe for C#) – that is pretty heavy activity. Process Explorer shows it clearly:
ASP.NET batch compilation occurs on per folder basis. Said that, if your application divided into multiple sub-folders that contain ASP.NET pages each time any of the folders accessed for the first time the batch compilation is invoked.
To overcome the issue we created simple solution we called ASP.NET Warmer. Complete description of the solution can be found here - Use FREE Tools From IIS Resource Kit To Warm Up Your ASP.NET 1.1 Application By Batch Compilation. The solution included three simple steps:
Customer reported high memory consumption and high CPU utilization that usually required process recycling. After quick code inspection we identified that the customer’s code uses XmlSerializer to serialize and deserialize types. The serializalbe type was built up of 250 properties. Each request generated 450 such types.
Tess has published complete lab with the source code and analysis for such case, including perfom snapshot (Tess, what a great resource!!). Here Process Explorer shows clearly activation of CSC.exe - C# compiler - on the fly during each request. Green – new instance, Red – disposed instance:
My name is Alik Levin and I am focusing on Security and Performance in .Net applications. When I do not blog about Security and Performance I blog about personal development.
This post was made with PracticeThis.com blog post template plugin for Windows Live Writer
PingBack from http://blog.a-foton.ru/2008/08/aspnet-performance-high-cpu-utilization-case-studies-and-solutions/
You've been kicked (a good thing) - Trackback from DotNetKicks.com
General The Tortoise And The Hare : Tim Barcz has a must-read post comparing enterprise development to the fable of the tortoise and the hare. As someone who's been dealing with this sort of cycle for the last few years, I couldn't agree more. Diligent
Over on the "ACE Team" blog there's a useful blog post with some performance tips for ASP.NET
ASP.NET Performance: High CPU Utilization Case Studies And Solutions