Django Live/Staging的服务器软件选择

使用Apache时,Windows上没有“单个进程”,只有一个Apache工作进程。另外,Windows上也没有守护程序模式。总之,这一切意味着两个Django实例都在一个进程中运行,尽管在不同的子解释程序中。所以是的,重新加载一个Django站点的代码会对另一个站点产生影响,因为它们处于相同的过程中。

如果一个进程在一个Unix系统上,那么它可以向工作进程/守护进程发送一个终止信号,这些进程将在不重新启动整个Apache的情况下重新启动。在Unix上,这不会过度导致问题,即使在接受HTTP请求的端口的侦听器套接字处于同一进程中的多个站点始终保持打开状态,因此在重新启动期间到达的后续请求只是排队,并将在工作进程/守护进程再次运行时进行处理。

在Windows上,当您正确选择整个Apache时,必须重新启动。这意味着,在非常短的时间内,监听器套接字将关闭,并且将有一个小窗口,在该窗口中,请求将获得失败的连接。这个窗口有多长时间,你真的需要做一些测试。通常情况下,这不是一个大问题,因为它足够短,请求在那个精确的时刻命中的概率很低。换句话说,如果您只是在谈论一个不希望经常重启的登台环境,那么您可能会过度担心。如果您试图在同一个Apache实例上运行开发站点,那么这将是一个问题。

这就是说,如果您希望登台实例尽可能接近生产,那么仍然需要运行Apache,因此不同端口上的多个Apache实例将是唯一的逻辑解决方案。您可以在Cherrypy WSGi服务器上运行Django,或者将WSGi服务器和代理粘贴到它上面,但它是一个不同的托管系统,并且其行为会有所不同,以至于您可能不会发现在生产设置时最终会发生的问题。

总之,我建议您在运行Apache基准测试的地方进行一些测试,同时执行重启,并查看结果中失败的请求数量。这将有助于你理解这是否是你认为的大问题。

默认情况下,Django会话是持久的,并支持数据库。重新启动Web服务器不会中断会话;当服务器恢复时,用户将像以前一样继续。重新启动后,cookie将显示会话密钥,数据库将调用会话变量,我们将继续不间断地进行。

http://docs.djangoproject.com/en/dev/topics/http/sessions/

如果您担心被劫持的会话,那么请缩短到期时间,关闭浏览器后销毁cookie,并定期从数据库中清除过期的会话。

至少我是这样读的。

我将坚持使用最常见的实现,因为这将使您获得最广泛的支持。我希望这是UNIX上的apache+mod wsgi。三分之二必须这样做。显然,登台和生产连接到同一个数据库。

您得到了我的兴趣,因为我正在考虑在另一个域名下建立一个“分段”部署,所以在我们测试完备用域名并准备好之后,我们只需交换apache conf中的“servername”变量即可开始运行。通过优雅的重新启动,我希望用户不会注意到它…除了突然出现的所有新功能之外:—)