重新加载mod_wsgi守护进程时的停机时间？

Question

我使用mod_wsgi在Apache上运行Django应用程序。升级过程中是否有停机时间？

Mod_wsgi在守护进程模式下运行，因此我可以通过触摸.wsgi脚本文件来重新加载我的代码，如“ReloadingSourceCode”文档中所述：http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode。据推测，该重新加载需要一些非零时间。如果在重新加载期间发出请求，会发生什么情况？ Apache将排队请求，然后在wsgi守护进程准备好后完成它？

文档包括以下语句：

所以，如果你在守护模式下使用Django和需要改变你的“settings.py”文件，一旦你已经完成了必要的改变，也碰包含WSGI应用程序入口点的脚本文件。完成之后，在下一个请求过程中将重新启动并重新加载Django应用程序。

对我而言，这表明Apache会优雅地处理每个请求，但我想我会要求确定。我的应用并不重要（有点宕机不会造成灾难性的），所以问题主要是学术问题。

谢谢。

Answer 1

在守护模式没有平稳重启的概念时WSGI脚本文件被触摸到强制下载。也就是说，与Apache本身不同，它将启动新的Apache服务器子进程，同时等待旧进程完成当前请求，对于mod_wsgi守护进程进程，现有进程必须在新进程启动之前退出。

这样做的后果是mod_wsgi的不能无限期地等待当前的请求完成。如果确实如此，那么存在这样的风险，即如果所有守护进程都被捆绑在等待当前请求完成的时候，那么客户端将会看到被处理的明显延迟。

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

因此，一个中间接地存在。守护进程将在退出之前等待请求完成，但是如果它们在关闭期间内没有完成，则守护进程将被强制退出，并且活动请求将被中断。

此关闭超时的周期默认为5秒。可以使用WSGIDaemonProcess指令的shutdown-timeout选项覆盖它，但应该考虑改变它的效果。

因此，就此特定问题而言，如果在触摸WSGI脚本文件后第一个请求进入时，长时间运行的请求仍处于活动状态，则存在长时间请求被激活的风险。

您可能会看到另一个值得注意的事情是，即使没有长时间运行的请求，并及时处理关机，那么它仍然需要在新的进程中又加载了WSGI应用。这需要的时间将被视为延迟处理请求。这个延迟有多大将取决于框架和您的应用程序。就我所知，启动时间最差的是TurboGears。 Django稍微好一点，最好的就是快速启动时间，像Flask这样的轻量级微框架。

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

Answer 2

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

会有服务器作为新的代码加载更小一点的负载，但除非你的应用是巨大的，你的服务器已经接近过载，这将是不明显的。

这就好比apachectl graceful命令为Apache作为一个整体，它告诉它来启动新的配置，无需停机。