Dylan Marks on Web Application Development

This week I spent some time with the excellent Jet Brains dotTrace Profiler, which allows you to see exactly how many milliseconds every method of your code is taking. I found the performance profiling quite easy to use, and within a few minutes I had already isolated a few problem areas in our application. 

One of the main trouble spots I came across was with the XslCompiledTransform class, which replaces the new obsolete XsltTransform class.  This class, new to .net 2.0, performs way faster because it actually loads and compiles the xslt into MSIL.  We rely heavily on xslts in our applications, with almost all html being defined in xslts instead of embedded inside app code. I’ll go into detail on this in a future post.

Using the profiler, I was noticing that loading xslt into XslCompiledTransform was taking a good 30-35% of the processing time for a page, since it is actually compiling the xslt on the fly. The solution? Either use caching, or make the compiled transform static, so that it reuses the same one instead of constantly recompiling it.

You may find my notes on httpcontext.cache helpful.

In order to really push the efficiency of your ASP.NET application, I recommend using the HttpContext.Cache object for data that rarely changes. One thing I was experiencing with a high volume site was seemingly random errors to do with accessing cached objects. Consider the following simple example:

if (HttpContext.Current.Cache[“myObject”] != null)
    Control ctrl = (Control) HttpContext.Current.Cache[“myObject”];

This seems foolproof: first you check if the object is in the cache, and only retrieve it if it is. The problem is that the Cache is accessed in a multi-threaded environment, and so there could be potentially thousands of separate web requests happening at once for this object, with some of them perhaps clearing the cache and re-adding a new copy. It’s entirely possible for the cache to become null in the microsecond between checking for existence and actually retrieving from it.  To make this matter worse, it’s a bug that will likely not be caught until on production with heavy traffic, and is very hard to duplicate effectively.  So the simple way to handle this (without messing with locks) would be to first retrieve into an object, check that object for null, and then cast it:

object cachedCtrl = HttpContext.Current.Cache[“myObject”];
if (cachedCtrl != null)
    Control ctrl = (Control) cachedCtrl;

Always Set an Expiration on a Cache

In order to avoid the dreaded OutofMemoryException, you should make sure you are not loading too much into the cache. One way of doing this is to place a rolling timeout on your cached object. That way if it’s not being used frequently it will automatically be discarded to free up memory for other activities:

HttpContext.Current.Cache.Insert(“MyObject”, myObject, null,
                            System.Web.Caching.Cache.NoAbsoluteExpiration,
                            TimeSpan.FromHours(1));

If you are experiencing OutOfMemoryExceptions because of this sort of situation, a quick fix would be to clear the Application Pool for that application in IIS. You can then configure the app pool to automatically recycle the working process after it has consumed too much memory.  Open up IIS Manager and right click the associated Application Pool:

Obviously this should be considered a temporary fix until you are able to test and push out a new version of code with more long term fixes.

On HttpContext and NUnit

Working directly with HttpContext makes writing Unit Tests difficult. When NUnit runs, it doesn’t have the same ASP.NET HttpContext to work with, and thus will throw an error when you try to access it in your code.  Instead of accessing HttpContext directly, lately I’ve used a facade-type object that mimics the interface of HttpContext.  If the context is available, it returns that, and if not, it returns simple collections for storing cache etc. I just found an excellent implementation by Phillip J Haack that does this better than my code, so I will direct you there instead of posting my version:  Simulating Http Context For Unit Tests Without Using Cassinni nor IIS.

I find the vast majority of documentation on using MSBuild to compile Visual Studio solutions is way too complicated.  MSBuild is very powerful, in that you can customize a lot of what is going on in the build process.  However, sometimes you just want to do a simple compile of a visual studio solution in your msbuild script, without having to worry about reconstructing references and other such nonsense.  It’s a one-liner task:

    <MSBuild Projects=“MySolution.sln”
           Properties=“Configuration=Debug“ ContinueOnError=“false“ />

I did a lot of research on MSBuild in the last month, and it was amazing just how long it took me to realise that MSBuild will parse .sln files for you.  I guess it was just too obvious (in other words, it says it right there if you go msbuild /? ).

You could do this from the command line as well instead of using devenv.exe: 
msbuild mysolution.sln /p:Configuration=Release

Solution files are not proper MSBuild scripts (unlike vbproj and csproj files), but MSBuild can still work with them. I recommend this excellent article by Sayed Ibrahim Hashimi if you want to go a bit deeper into using the solution file in MSBuild.  He talks about generating a proper .proj file from a solution file with a custom task, and then working with that for any other customization you require in your build process.