Does editing a Web.config file trigger an overlapping recycle or a start+stop of the application pool?

Question

I have Overlapping Recycling configured for my ASP.NET MVC site.

As I understand it (from this SO question), if I Recycle the Application Pool, this will spin up a new w3wp.exe process to take up the load of the one being recycled, and only when the new process is initialised and taking the load, will the old process be shut down. And if I stop/start the Application Pool, it does an immediate kill without letting the process quit gracefully or letting a replacement process spin up first.

Question: when I edit my Web.config file, it will restart the associated IIS Application Pool. Is this going to trigger the nice overlapping recycling behaviour, or the brutal stop/start behaviour?

I'm trying to decide if I need to take a server out of a load-balanced farm and do a drain-stop on the server traffic in order to edit configuration settings.

Answer 1

I decided to use science. I ran an experiment with my server under a load-testing tool, where I repeatedly edited and saved my Web.config file while requests were poured in.

No requests were dropped when changes were saved to the Web.config file.

I did observe a short spike in CPU activity while the new settings were loaded, but really barely noticeable at all.

I was able to prove that the settings were getting loaded by making the Web.config file badly formatted and saving it. This immediately caused requests to start failing.

What surprised me is that the process id did not change with a Web.config edit. My understanding of the IIS Overlapping Recycle was for IIS to start a new w3wp.exe process, and then wind down the old one. Which would have meant a different process id. So I don't think Overlapping Recycle is kicking in here.

Since the process id is the same, then I reason that its a totally separate mechanism which loads/unloads the AppDomain. This seems to be supported by this document, the relevant bit is reproduced below:

Configuration Changes Cause a Restart of the Application Domain

Changes to configuration settings in Web.config files indirectly cause the application domain to restart. This behavior occurs by design. You can optionally use the configSource attribute to reference external configuration files that do not cause a restart when a change is made. For more information, see configSource in General Attributes Inherited by Section Elements.

TLDR

Neither Overlapping Recycle, or the brutal stop/start behaviour are caused by a Web.config edit. The AppDomain is re-loaded with the new settings without interruption to request processing.

http://msdn.microsoft.com/en-us/library/ackhksh7.aspx

Answer 2

Editing (or touching) the web.config will not trigger a 'nice overlapping recycling'. As described above, the request process will not been 'interrupted' but new incoming requests have to wait until the new worker process has finished its initialization. So depending on the time for initialization, there will be a noticeable break. I noticed that on a WCF-Service Application hosted in IIS7.5 where I implemented IProcessHostPreloadClient to do some time expensive preload stuff. On the other hand a 'recycle' by clicking the app-pool's context menu item at the IIS Manager will do the nice overlapping: New incoming requests are processed by the old worker process as long as the new one works on the preload method.