编辑 web.config - 导致停机？
在我正在使用的一个网站上，他们可以要求我们进行两类更改。一方面，他们有我必须重建和重新部署的东西。他们将这些视为“停机”更改，因为我们显示了一个漂亮的小启动屏幕，并且当我们恢复时我们会彻底测试站点。
另一方面，他们要求我们进行一些文本更改、打开和关闭功能等，我们已将其隔离到 web.config。我们提供在部署窗口内部或外部执行这些操作 - 我们只需编辑文件，检查更改是否正确，然后返回工作。
但客户端的一位聪明人指出，编辑 web.config 会回收应用程序池，这就是停机时间。我从来没有注意到，但我认为这是正确的 - 当应用程序池不可用时，应用程序就会“关闭”。
但持续多久呢？我并不是要求您对客户对停机时间间隔的舒适程度进行排序，但这是否是一个常见的观点？或者我们不应该担心 web.config 编辑会导致应用程序停机一两秒吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
到目前为止所有说的都是正确的。
但是，只要不缓存您提取的值，就有一种方法可以避免这种停机。
您可以将 .config 文件的一部分移植到另一个文件，这不会回收应用程序池。
它在 web.config 文件中看起来像这样：
然后你的外部文件看起来像这样：
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:
Then your outside file would look like this:
IIS 通常会自行回收应用程序池，如果这些回收不会引起您的担忧，那么这一次也不应该引起您的担忧。
据我所知，用户不应该收到任何类型的“服务不可用”错误。
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.
如果您非常担心停机时间，并且这种情况经常发生，我会考虑将这些设置移至数据库。
也就是说，您的情况下的停机时间将是最短的。当您保存 web.config 文件时，应用程序池将被回收，我们谈论的是毫秒。
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.
如前所述，IIS 确实在回收应用程序池。不过，这并不像执行完整的 iisreset 那么糟糕 - 用户不应该得到“服务不可用”的信息。错误，因为 Web 服务器仍然在线并正在处理请求 - 它只需要等待 AppPool 重新启动，这意味着此时用户访问的响应时间非常长。如果您有一个公共网站并且拒绝访问者，这当然可能是一个问题。
AppPool 回收的其他副作用与 iisreset 相同：如果我没记错的话，它会刷新 InProc 会话缓存，并执行 Application_Start 事件。
因此，尽管它相对无害，但我仍然将其视为停机时间。
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.