python - 重新加载 mod_wsgi 守护进程时停机？

Question

我正在使用 mod_wsgi 在 Apache 上运行 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 将优雅地处理每个请求，但我想我会要求确定。我的应用程序并不重要(稍微停机也不会造成灾难性的后果)，所以这个问题主要是学术性的。

谢谢。

Answer 1

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

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

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

因此存在中间立场。守护进程会等待请求完成后退出，但如果在关闭时间内还没有完成，则守护进程将被强制退出，并中断活跃的请求。

此关机超时时间默认为 5 秒。可以使用 WSGIDaemonProcess 指令的关闭超时选项覆盖它，但应适当考虑更改它的影响。

因此，对于这个特定问题，如果在您触及 WSGI 脚本文件后第一个请求到来时您的长时间运行的请求仍然处于事件状态，则存在事件的长时间请求将被中断的风险。

您可能会看到的下一个值得注意的事情是，即使没有长时间运行的请求并且进程迅速关闭，仍然需要在新进程中再次加载 WSGI 应用程序。这花费的时间将被视为处理请求的延迟。延迟有多大取决于框架和您的应用程序。据我所知，就启动时间而言，最糟糕的违规者是 TurboGears。就快速启动时间而言，Django 稍微好一些，最好的是轻量级微框架，例如 Flask。

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