The first request to an ASP.NET application after an IIS restart is always the slowest. Application pool recycling, a server reboot, or a config change forces the worker process to recompile assemblies and warm caches, and that first user pays the entire cost \u2014 often five to thirty seconds of spinner. Application Initialization, built into IIS 8 and later, lets the server do that work before it accepts traffic.<\/p>\n\n\n\n
If your application recycles nightly, if you deploy frequently, or if you run more than one node behind a load balancer, warmup turns a user-visible freeze into a background task. For a single long-running app pool that recycles weekly, the payoff is smaller but the setup cost is near zero, so there is little reason to skip it.<\/p>\n\n\n\n
The role service is called Application Initialization<\/em>. Install it in an elevated PowerShell session:<\/p>\n\n\n\n If you manage IIS with the Configuration Editor rather than feature management, the module appears under Two switches must both be set: the application must be marked for preload, and the pool must start automatically. Missing either one silently disables the whole mechanism.<\/p>\n\n\n\n Setting Preload alone starts the process; it does not exercise the application. Add a IIS will not route traffic to the site until those pages return a successful status. Design There is a tradeoff to respect: IIS now waits for your warmup pages before serving traffic, so a slow warmup becomes deployment latency. Keep warmup endpoints fast and idempotent, and cap their runtime at a few seconds. If warmup fails, IIS retries rather than serving a cold site \u2014 consider that a feature, but monitor the failed-request log so a broken warmup endpoint does not look like an outage.<\/p>\n\n\n\n Warmup matters most when more than one node serves traffic. Without it, a rolling deployment or a pool recycle on one node sends that node’s share of requests into a cold app while its peers are already warm \u2014 the imbalance shows up as a latency spike that looks like a network problem. With preload enabled on every node, the load balancer only needs a health probe that respects the same warmup endpoint.<\/p>\n\n\n\n Application Initialization does not override the recycle schedule \u2014 it complements it. Leave a scheduled recycle in place for the memory-reclamation benefit, but pair it with overlapping recycle so a new worker process starts and warms before the old one retires. Check the pool’s Disable Overlapped Recycle<\/em> setting is off:<\/p>\n\n\n\n Overlapped recycle combined with a warmup page means users never touch a cold process, even during a scheduled recycle. This single pairing eliminates the most common “the site is slow every night at 3am” complaint.<\/p>\n\n\n\n Each of these produces the same symptom \u2014 a first request that is still slow \u2014 so work through the list in order when warmup appears not to work.<\/p>\n\n\n\n Set up correctly, Application Initialization removes the cold-start penalty entirely and makes deployments invisible to users instead of a brief outage. It is one of the highest-value ten-minute IIS changes available, particularly on VPS deployments that lack the spare capacity to absorb a stampede of cold requests.<\/p>\n","protected":false},"excerpt":{"rendered":"Install-WindowsFeature Web-AppInit\n\n# verify it loaded\nGet-WebGlobalModule | Where-Object Name -eq 'ApplicationInitializationModule'<\/code><\/pre>\n\n\n\nsystem.webServer\/applicationInitialization<\/code> at the server level.<\/p>\n\n\n\nStep 2: Enable preload on the application and the pool<\/h2>\n\n\n\n
Import-Module WebAdministration\n\nSet-ItemProperty IIS:\\Sites\\MyApp -Name applicationDefaults.preloadEnabled -Value $true\nSet-ItemProperty IIS:\\AppPools\\MyApp -Name startMode -Value AlwaysRunning\nSet-ItemProperty IIS:\\AppPools\\MyApp -Name processModel.idleTimeout -Value \"00:00:00\"<\/code><\/pre>\n\n\n\nidleTimeout<\/code> to zero stops IIS from unloading the worker process after twenty minutes of inactivity. Combined with AlwaysRunning<\/code>, the app stays resident and warm between requests.<\/p>\n\n\n\nStep 3: Declare a warmup URL<\/h2>\n\n\n\n
web.config<\/code> entry pointing at a lightweight endpoint that touches the expensive paths without doing real work.<\/p>\n\n\n\n<system.webServer>\n <applicationInitialization doAppInitAfterRestart=\"true\">\n <add initializationPage=\"\/warmup\" \/>\n <add initializationPage=\"\/health\/db\" \/>\n <\/applicationInitialization>\n<\/system.webServer><\/code><\/pre>\n\n\n\n\/warmup<\/code> to prime the things that are actually slow: JIT-compile controller types, open the database connection pool, load configuration, and populate any in-memory cache.<\/p>\n\n\n\nWarmup target<\/th> Why it helps<\/th> Cost<\/th><\/tr><\/thead> Razor\/compiled views<\/td> First render is fast<\/td> Low<\/td><\/tr> DB connection pool<\/td> First query does not pay handshake<\/td> Low<\/td><\/tr> In-memory cache<\/td> Avoids cold-start stampede<\/td> Medium<\/td><\/tr> External API clients<\/td> DNS and TLS warm<\/td> Medium<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Step 4: Do not slow down deployment<\/h2>\n\n\n\n
Multi-node and load-balanced deployments<\/h2>\n\n\n\n
Deployment style<\/th> Cold-start exposure<\/th> Warmup value<\/th><\/tr><\/thead> Single node, weekly recycle<\/td> One window<\/td> Moderate<\/td><\/tr> Rolling deploy, 2+ nodes<\/td> Per-node spike<\/td> High<\/td><\/tr> Autoscaling instances<\/td> Every scale-out<\/td> Very high<\/td><\/tr> Blue\/green swap<\/td> On cutover<\/td> High<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Interaction with recycle settings<\/h2>\n\n\n\n
Get-ItemProperty IIS:\\AppPools\\MyApp `\n -Name recycling.disallowOverlappingRotation\n# Value should be False; set it explicitly if it is not\nSet-ItemProperty IIS:\\AppPools\\MyApp `\n -Name recycling.disallowOverlappingRotation -Value $false<\/code><\/pre>\n\n\n\nCommon pitfalls that silently break warmup<\/h2>\n\n\n\n
applicationInitialization<\/code> section.<\/li>\nVerify it worked<\/h2>\n\n\n\n
Restart-WebAppPool -Name MyApp<\/code><\/li>\n%SystemDrive%\\inetpub\\logs\\LogFiles<\/code> for the warmup hits before any user request.<\/li>\nGet-Process w3wp<\/code> should show it resident.<\/li><\/ol>\n\n\n\n