Minimize startup time for asp.net

I have multiple web services (WCF) running in IIS. When the services are warm (loaded), typical requests take about 0.5 seconds to complete. However, when the application is not warm (cold start), the first hit takes some 20 seconds before the service is up and running. The same happens when an app pool recycle occurs.

I'm looking to reduce the cold start times for this web service. Some actions i have already performed are:

• Configured the application pool so that it doesn't recycle after 20 min, idle time (so that the application stays warm). This minimizes the occurence of cold starts, but doesn't make cold starts faster. app pool recycles are now limited, but do stil occur.

• Modified the machine.config,

like this:

<runtime>
    <!-- see http://msdn.microsoft.com/en-us/library/bb629393(v=vs.90).aspx -->
    <generatePublisherEvidence enabled="false"/>
</runtime>

This reduces startup times from 20 secs to about 10 secs.

• I've tried using NGEN to precompile the assemblies,

like开发者_Go百科 this

for %d in (*.dll) do ngen install %d

This doesn't reduce startup times (only adds complexity to deployment).

I would really like to reduce the cold start times even further. What options do i have to do this?

(on a side note: what is the best way to find out where the time is spend during startup? how do i monitor what's going on?)

---

Update

I've done some further testing with procmon. There doesn't seem to be one single cause of the start up time, it's a whole lot of little timeslices (proces start, loading ,net runtime, reading configuration, loading assemblies, etc..) that add up to the total time.

---

I've had decent luck with the strategy found in this article. It keeps the application alive so that once it's running, you just won't have any cold starts (unless IIS or the machine is actually restarted intentionally or as the result of a significant error). The app keeps itself alive regardless of any activity.

The article is about scheduling something to happen every so-often, but you can skip that part if your only goal is to keep the app alive.