views:

140

answers:

4

On a site I'm working with, we've got two classes of changes they can ask for. On one hand, they've got stuff that I'd have to rebuild and redeploy. They count these as "downtime" changes, because we display a nice little splash screen and we test the site thoroughly when we come back up.

On the other hand, they ask us to do a number of text changes, turning features on and off, etc., which we've isolated to the web.config. We offer to do these either inside or outside of deployment windows - we just edit the file, check that the change is right, and go back to work.

But one of the smart guys on the client side pointed out that editing web.config recycles the app pool, and that's downtime right there. I'd never noticed, but I suppose that's right - while the app pool is unavailable, the app is "down".

But for how long? I'm not asking you to sort through the client's level of comfort with downtime intervals, but is this a common perspective? Or should we just not worry that web.config editing is accompanied by a second or two of application downtime?

+2  A: 

If you're concerned at all with downtime, and this happens a lot, I would consider moving these settings to the database.

That said, the downtime in your case will be minimal. The app pool is recycled when you SAVE the web.config file, and we're talking milliseconds.

Gabriel McAdams
+2  A: 

IIS recycles the app pool by itself normally, and if those recycles don't cause you concern, this once shouldn't either.

The user shouldn't receive any sort of "service unavailable" errors, afaik.

Greg
This. App pools are recycled on a regular basis anyway, depending on your settings (time, memory consumption, etc...). A simple web.config change should not affect your app adversely unless you're doing something silly like using in-proc session state (and if you are, that's where you should direct your effort to fix something).
Chris
+3  A: 

All said so far is correct.

However there is a way to avoid this downtime, as long as your values you are pulling are not cached.

You can port part of your .config file to another file, that won't recylce the app pool.

It would look something like this in the web.config file:

<appSettings file="moresettings.config"></appSettings>

Then your outside file would look like this:

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>   
<add key="SOMEKEY" value="MYVALUE"/>
</appSettings>
Clarence Klopfstein
+1  A: 

As said, IIS is indeed recycling the App Pool. This is not as bad as doing a full iisreset though - users shouldn't get the "Service unavailable." error as the Web Server is still online and serving requsts - it just has to wait for the AppPool to restart, which means that the response time for the users accessing in this moment are very high. This may be a problem of course if you have a public website and are turning visitors away.

The other side effects of AppPool recycling are the same as an iisreset: It flushes an InProc Session Cache if I'm not mistaken, and it executes the Application_Start event.

So even though it's relatively harmless, I would still treat it as downtime.

Michael Stum