重新加载mod_wsgi守护程序时出现停机? [英] Downtime when reloading mod_wsgi daemon?

问题描述

我正在使用mod_wsgi在Apache上运行Django应用程序.升级期间会不会有停机时间?

I'm running a Django application on Apache with mod_wsgi. Will there be any downtime during an upgrade?

Mod_wsgi在守护程序模式下运行，因此我可以通过触摸.wsgi脚本文件来重新加载代码，如"ReloadingSourceCode"文档中所述:

Mod_wsgi is running in daemon mode, so I can reload my code by touching the .wsgi script file, as described in the "ReloadingSourceCode" document: http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode. Presumably, that reload requires some non-zero amount of time. What happens if a request comes in during the reload? Will Apache queue the request and then complete it once the wsgi daemon is ready?

文档包含以下语句:

因此，如果您在守护程序模式下使用Django并需要更改"settings.py"文件，则在进行了必要的更改后，还请触摸包含WSGI应用程序入口点的脚本文件.完成此操作后，在下一个请求下，该过程将重新启动，并重新加载您的Django应用程序.

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将正常处理每个请求，但是我想我要确保确定.我的应用程序不是很严格(停工时间不会造成灾难性的后果)，因此问题主要是学术性的.

To me, that suggests that Apache will gracefully handle every request, but I thought I would ask to be sure. My app isn't critical (a little downtime wouldn't be disastrous) so the question is mostly academic.

谢谢.

推荐答案

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

In daemon mode there is no concept of a graceful restart when WSGI script file is touched to force a download. That is, unlike Apache itself, which will start new Apache server child processes while waiting for old processes to finish up with current requests, for mod_wsgi daemon processes, the existing process must exit before a new one starts up.

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

The consequences of this are that mod_wsgi can't wait indefinitely for current requests to complete. If it did, then there is a risk that if all daemon processes are tied up waiting for current requests to finish, that clients would see a noticeable delay in being handled.

但是，在另一端，无法立即终止守护进程，因为这会导致当前请求被中断.

At the other end of the scale however, the daemon process can't be immediately killed as that would cause current requests to be interrupted.

因此存在中间立场.守护程序进程将等待请求完成再退出，但是如果它们在关闭时间内仍未完成，则该守护程序进程将被强制退出，并且活动请求将被中断.

A middle ground therefore exists. The daemon process will wait for requests to finish before exiting, but if they haven't completed within the shutdown period, then the daemon process will be forcibly quit and the active requests will be interrupted.

此关闭超时的时间默认为5秒.可以使用WSGIDaemonProcess指令的shutdown-timeout选项来覆盖它，但应适当考虑更改它的效果.

The period of this shutdown timeout defaults to 5 seconds. It can be overridden using the shutdown-timeout option to WSGIDaemonProcess directive, but due consideration should be given to the effects of changing it.

因此，就这个特定问题而言，如果您在触摸WSGI脚本文件后第一个请求出现时仍然有长时间运行的请求仍处于活动状态，则存在活动的长期请求被中断的风险.

Thus, in respect of this specific issue, if you have long running requests still active when the first request comes in after you touched the WSGI script file, there is the risk that the active long requests will be interrupted.

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

The next notable thing you may see is that even if there are no long running requests and processes shutdown promptly, then it is still necessary to load up the WSGI application again within the new process. The time this takes will be seen as a delay in handling the request. How big that delay is will depend on the framework and your application. The worst offender as far as time taken to start up that I know of is TurboGears. Django somewhat better and the best as far as quick start up times being lightweight micro frameworks such as Flask.

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

Do note that any new requests which come in while these shutdown and startup delays occur should not be lost. This is because the HTTP listener socket has a certain depth and connections queue up in that waiting to be accepted. If the number of requests arriving is huge though and that queue fills up, then you will start to see connection refused errors in the browser.

这篇关于重新加载mod_wsgi守护程序时出现停机?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！