In my experience working with IIS, when a worker process is recycled, the next request to "activate" the new process has to wait whilst the process performs it's one-time startup. This wait can be particularly bad when programs are doing quite large application startups.

Is there a way through IIS to keep a minimum number of worker processes in a "ready" state, so they will serve requests immediately? I still want worker processes to be recycled, but for them not to serve requests until they're in a "ready" state, so users don't feel the startup cost.


In 7.5 (Windows Server 2008 R2) you can use the startMode property to ask the App Pool to boot even without a request coming in. By default, they're still demand-started (at least, so says the documentation), but adding this attribute to an applicationPool should allow it to noodle around happily, even while idle.


I agree with rfair01 though, in that it's probably a better idea not to have them recycle in the first place; this isn't always feasible, though.


There are a couple of different things you can do:

1) Change your app pool so that it does not automatically recycle. This will keep your application ready at all times unless IIS is restarted. If you are in a shared hosting situation, this may not be practical. If you have memory issues with the application, this may not be a good approach either.

2) Use a scheduled warmup script. If app pools are on a schedule to recycle, you can create a script that will hit a page on your site to warm up the app pool. Example here. That way your application should be ready to respond quickly to requests.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.