In order to speed up reaction time of our ASP.NET MVC application, we'd like to "warm up" the application after it has been installed (or after the app pool has been recycled). Some frequently used lookup data should be fetched from the SQL Server database, and stored into the global System.Runtime.Caching.MemoryCache
object that .NET provides.
For a situation where you have a dedicated VM with a dedicated IIS for your ASP.NET app, I first of all set the app pool to be "Always Running" - that's step #1.
Given this situation, there are two options I see:
Application warmup as described in this blog post by Scott Gu based on the
System.Web.Hosting.IProcessHostPreloadClient
interface. If I understand correctly, this code runs when the app pool is started, and before the first request is accepted into the applicationUse the
Application_Start
event inglobal.asax.cs
. If I understand correctly, this event is called only once, when the application is started for the first time (which would happen automatically after installation, since the app pool is set to be "Always Running" - right?)
So - given this setup - which is the preferred way of "pre-warming" your application? Are there any significant differences between these two approaches? What do I need to be aware of when going with one approach over the other?
Thanks for any inputs, hints, warnings, or further links explaining this in more detail!
The short answer, use
IProcessHostPreloadClient
-- it will run immediately on startup.Application_Start
is a bit of a misnomer, it actually fires on the first request. That means the site might recycle/restart and be sitting idle, where it could be warming.If your site is on IIS 7 or above I'm not aware of a reason to use
Application_Start
.