And*_*ewF 5 python apache django mod-wsgi
我正在使用mod_wsgi在Apache上运行Django应用程序.升级期间会有停机时间吗？
Mod_wsgi以守护进程模式运行,因此我可以通过触摸.wsgi脚本文件重新加载我的代码,如"ReloadingSourceCode"文档中所述:http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode.据推测,重新加载需要一些非零时间.如果在重新加载期间有请求,会发生什么？Apache会将请求排队,然后在wsgi守护程序准备就绪后完成它吗？
该文档包括以下声明:
因此,如果您在守护程序模式下使用Django并且需要更改"settings.py"文件,则在完成所需更改后,还要触摸包含WSGI应用程序入口点的脚本文件.完成后,在下一个请求中,将重新启动进程并重新加载Django应用程序.
对我来说,这表明Apache将优雅地处理每个请求,但我想我会要求确定.我的应用程序并不重要(一点停机时间不会是灾难性的)所以问题主要是学术问题.
谢谢.
Gra*_*ton 18
在守护进程模式下,当触摸WSGI脚本文件以强制下载时,没有正常重启的概念.也就是说,与Apache本身不同,它将在等待旧进程完成当前请求时启动新的Apache服务器子进程,对于mod_wsgi守护程序进程,现有进程必须在新进程启动之前退出.
这样做的后果是mod_wsgi无法无限期地等待当前请求完成.如果确实如此,则存在这样的风险:如果所有守护进程都等待当前请求完成,则客户端将看到明显的处理延迟.
但是,在规模的另一端,守护进程不能立即被杀死,因为这会导致当前请求被中断.
因此存在中间立场.守护进程将在退出之前等待请求完成,但如果它们在关闭期间未完成,则守护进程将被强行退出,并且活动请求将被中断.
此关闭超时的时间默认为5秒.可以使用WSGIDaemonProcess指令的shutdown-timeout选项覆盖它,但应该适当考虑更改它的效果.
因此,对于此特定问题,如果在触摸WSGI脚本文件后第一个请求进入时仍有长时间运行请求仍处于活动状态,则存在活动长请求将被中断的风险.
您可能会看到的下一个值得注意的事情是,即使没有长时间运行的请求和进程立即关闭,仍然需要在新进程中再次加载WSGI应用程序.这段时间将被视为处理请求的延迟.延迟有多大将取决于框架和您的应用程序.据我所知,最糟糕的犯罪者是启动时间是TurboGears.Django稍微好一点,最快的启动时间是Flask这样的轻量级微框架.
请注意,在这些关闭和启动延迟发生时进入的任何新请求都不应丢失.这是因为HTTP侦听器套接字具有一定深度,并且连接排队等待接受.如果到达的请求数量很大并且该队列已填满,那么您将开始在浏览器中看到连接拒绝错误.