Application is busy under initialization phase

A feature was introduced with SP1 to EPiServer CMS 5 R2, that I (and the product team) have gotten some mixed feedback on. The feature involves the text “Application is busy under initialization phase” to be displayed when EPiServer CMS is starting up, and tends to be quite visible – especially to developers that are constantly restarting the web-site – so after some investigation I thought I’d give some background into why it was introduced – and what you can do about it.

Background

Whenever an EPiServer CMS web application starts a number of initialization steps needs to be taken. There’s the usual asp.net stuff like JIT-compilation, assembly caching, etc. but also more EPiServer specific stuff like loading language files, scanning assemblies for plugins, initializing the plugins, running custom initalization code, preloading of cache and so on. And things take time. On large sites with huge customizations and many languages it can easily take 15-30 seconds. This process is initiated by the very first web request to the application, after a restart. The following requests used to just be queued and then executed once the initialization was done. However, this turned out to be a problem in high-traffic sites, since you could have a lot of requests piling up, potentially taking down the server, so in EPiServer CMS 5 R2 SP1 the behavior was changed so that subsequent requests that comes while init is in progress will be instantly returned with the text above.

Since developers typically recompile a lot – and thereby restarting the site – they will often see the error. If they are anything like me, they probably even have a browser window opened in edit or admin mode – and when refreshing that after a recompile some of the frames will return with the busy message.

Solution

Now, what can you do about this? Here’s a couple of hints:

1. Don’t panic. If you environment is setup correctly, odds are you’ll most likely see this when you are developing – not in production.
2. Avoid restarting your application often in production. Avoid IIS settings that “recycles” the IIS after X minutes of inactivity – especially in cluster setups some servers can restart themselfes that way.
3. If you for some reason feel more comfortable knowing that your IIS gets recycled once a night, setup a web-monitor tool to ping the website with a request shortly after the recycle in order to initialize it.
4. Look into cutting down the initialization time. Lots of tricks exists for this:
   a) Remove xml files from the “lang” folder you don’t use on your site
   b) Look into using aspnet_compile 
   c) If you do a lot of custom work on startup – like building an in-memory index of some property for fast lookup, etc – do it in a separate thread (or ThreadPool job), to keep it from blocking other requests.
5. If you are still concerned that your end users might face this error, go back to step 1…Or contact support – they have a patch that will allow you to select the pre-SP1 handling.

Future

I have been told that in the next service pack, the functionality will be changed, so that you can either have the ‘old’ queuing handling or return a custom error message – which this time also will be returned with HTTP 503 – which is more fitting than the current 200 status code.