0

OS: Windows Server 2012 Standard

IIS: 8.0.9200.16384

Processor: 4x Xeon 2.67Ghz CPU

RAM: 40GB

Problem:

We have recently enabled IIS's AutoStart feature, since doing so our start up time for the application pools has gone up considerably. The application pool appears to be running but it seems to ramp up its CPU usage to the maximum 25% for about 30 minutes and the websites running in that pool don't respond until this has completed. We have checked the event log and there doesn't appear to be any faults. We have checked the logging in our preload function and this appears to only take about 60-90 seconds.

How can we diagnose what is causing the delay in the application pools starting up?

Background:

We are serving up multiple copies of the same ASP.Net MVC3 application, from multiple application pools (20 sites per pool). We have approximately 8 pools service up 160 sites We have IProcessHostPreloadClient built which preloads some settings from the database when the sites starts up. We have a second server with the same basic specs but only 3 pools of 20, which only takes approx 5 minutes per pool to start up.

1 Answers1

0

For anyone interested here is what we did to resolve/mitigate the issue:

  1. Break up our sites into smaller groupings per application pools (this reduces the startup time per application pool). We went with 10 sites per pool.
  2. Change to using the IIS 8 Application Initialize 'PreloadEnabled' option rather than the serviceAutoStartProvider for site initialization.
  3. When deploying new code, don't restart the application pools, instead use the app_offline.htm feature to unload the application and restart it.

The app_offline.htm feature is the key one for us, this means we are able to deploy new versions of our software with out stopping and starting the application pools and incurring the start up time penalty. Also incrementally restarting application pools help reduce the strain on the CPU which meant we got a consistent start up time for each pool. This is only required when we do an IIS reset or server restart (rarely).