重新加载mod_wsgi守护程序时会出现停机时间吗？

Question

我正在使用Apache和mod_wsgi运行Django应用程序。在升级过程中会有任何停机时间吗？

Mod_wsgi正在守护进程模式下运行，因此可以通过触摸.wsgi脚本文件重新加载代码，如“ReloadingSourceCode”文档所述：http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode。假设该重新加载需要一些非零时间。如果在重新加载期间收到请求会发生什么？Apache会将请求排队，然后在wsgi守护进程准备就绪后完成请求吗？

文档包括以下声明：

“So，if you are using Django in daemon mode and needed to change your 'settings.py' file, once you have made the required change, also touch the script file containing the WSGI application entry point. Having done that, on the next request the process will be restarted and your Django application reloaded.”

对我来说，这表明Apache将优雅地处理每个请求，但我想确认一下。我的应用程序并不重要（短暂的停机时间不会造成灾难），因此这个问题主要是学术性的。

谢谢。

- AndrewF

Answer 1

在守护进程模式下，当需要强制下载WSGI脚本文件时，不存在优雅重启的概念。也就是说，与Apache本身不同，Apache将在等待旧进程完成当前请求的同时启动新的Apache服务器子进程，但对于mod_wsgi守护进程进程而言，在新进程启动之前必须退出现有进程。

这样做的后果是，mod_wsgi无法无限期地等待当前请求完成。如果这样做，那么如果所有守护进程都被绑定在等待当前请求完成上，客户端将会看到明显的延迟。

然而，在另一方面，守护进程进程也不能立即被杀死，因为这会导致当前请求被中断。

因此存在一个折衷方法。守护进程将等待请求完成后退出，但如果它们在关机期间没有完成，则守护进程将被强制退出，活动请求将被中断。

默认情况下，此关机超时期为5秒。可以使用shutdown-timeout选项覆盖WSGIDaemonProcess指令，但应考虑更改的影响。

因此，在关于这个特定问题方面，如果在触摸WSGI脚本文件后的第一个请求时仍有长时间运行的请求处于活动状态，则存在中断活动长请求的风险。

您可能会看到的下一个显着问题是，即使没有长时间运行的请求并且进程及时关闭，仍然需要在新进程中重新加载WSGI应用程序。这需要一些时间并会被视为处理请求的延迟。这个延迟的大小取决于框架和应用程序。就我所知，最耗时的是TurboGears，Django稍微好一些，而启动时间最快的是轻量级微框架，如Flask。

请注意，在出现这些关闭和启动延迟的同时到达的任何新请求都不应该丢失。这是因为HTTP侦听器套接字具有一定的深度，并且连接排队等待被接受。但是，如果到达的请求数量很大并且该队列已满，则浏览器中将开始看到连接被拒绝的错误。

- Graham Dumpleton

---

这些额外的背景信息非常有用。我之前只考虑到新的请求，而没有考虑到长时间运行的先前请求，但你所描述的很有道理。谢谢。 - AndrewF

顺便提一下，当mod_wsgi 4.0可用时，它将开始引入一些稍微更为优雅的重新加载选项。 - Graham Dumpleton

Answer 2

不会有停机时间。使用旧代码的请求将完成，新请求将使用新代码。

服务器将承载更多负载，因为新代码正在加载，但除非您的应用程序庞大且服务器已经接近超载，否则这将是不可察觉的。

这就像对整个Apache执行apachectl graceful命令，告诉它在没有停机时间的情况下启动新配置。

- poolie

---

并不涵盖整个情况。可能会出现延迟以及请求被中断的情况。请查看我的回答。 - Graham Dumpleton