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.

Hearth

I don't know for sure, but web.config changes are handled on ASP.Net level. It has file watcher that watches for that file and a couple of directories. And Overlappign Recycling is IIS thing, so as for me it will do brutal stop\start. – Rubberize

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

Hearth

Good work! I had often wondered about the differences, and why a config change was often quicker to 'restart' compared to an app pool recycle. – Isomeric

Yes, editing web.config in ASP.NET (not Core) will keep the same process id. The process is the same. It just reload the AppDomain. But this happens within the same process. With ASP.NET CORE things are different however. A new copy of w3wp process is launched by AspNetCoreModule – Denial

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.

Plate