部署 Django（fastcgi、apache mod_wsgi、uwsgi、gunicorn）答案

【问题标题】：Deploying Django (fastcgi, apache mod_wsgi, uwsgi, gunicorn)部署 Django（fastcgi、apache mod_wsgi、uwsgi、gunicorn）
【发布时间】：2011-02-05 05:02:34
【问题描述】：

谁能解释守护进程模式下的 apache mod_wsgi 和线程模式下的 django fastcgi 之间的区别。我认为他们都使用线程进行并发。 假设我使用 nginx 作为 apache mod_wsgi 的前端。

更新：

我正在比较 django 内置的 fastcgi（./manage.py 方法=线程 maxchildren=15）和 mod_wsgi 在“守护进程”模式（WSGIDaemonProcess 示例线程=15）。他们都使用线程并获取 GIL，对吗？

UPDATAE 2：

如果它们都相似，apache mod_wsgi 对 fastcgi 有什么好处。我看到了 fastcgi 的这些优点：

我们不需要 apache
我们消耗更少的 RAM
我注意到 fastcgi 的开销较小

UPDATAE 3：

我现在对 nginx + uwsgi 很满意。

UPDATAE 4：

我现在对 nginx + gunicorn 很满意 :)

【问题讨论】：

标签： python django deployment fastcgi mod-wsgi

【解决方案1】：

不必使用线程来处理并发请求。这取决于您如何配置它们。如果需要，您可以使用多个进程，其中每个进程都是单线程的。

有关 mod_wsgi 进程/线程模型的更多背景信息，请参阅：

http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

这些模型是相似的，尽管 mod_wsgi 自己处理进程管理。就进程管理而言，FASTCGI 中发生的事情取决于您使用的 FASTCGI 托管机制，而您没有说是什么。

另一个区别是 FASTCGI 仍然需要一个单独的 FASTCGI 到 WSGI 的桥接器，例如 Flup，而 mod_wsgi 不需要任何类型的桥接器，因为它本身就实现了 WSGI 接口。

最后，FASTCGI 进程是某个主管进程或 Web 服务器的 exec/fork，取决于托管机制。在 mod_wsgi 中，进程只是 Apache 父进程的一个分支。一般来说，这并不重要，但确实有一些影响。

还有其他差异，但它们的出现更多是因为 mod_wsgi 提供了比 FASTCGI 托管机制更多的功能和可配置性。

无论如何，这个问题有点模糊，您能否更具体地说明您想知道什么或两者之间的对比以及为什么？那么答案可能会更有针对性。

【讨论】：

我正在比较 django 内置的 fastcgi(./manage.py method=threaded maxchildren=15) 和 mod_wsgi 在 'daemon' 模式(WSGIDaemonProcess example threads=15)。
是的，它们都依赖多线程来处理并发请求。即使使用单线程 WSGI 服务器也使用 GIL，如果不重新编译 Python 源代码并禁用线程支持，您也无法轻松避免它。但是这样做你不能使用 mod_wsgi，因为它不支持禁用线程的 Python。
“即使使用单线程 WSGI 服务器也使用 GIL”是什么意思？当我们将 mod_wsgi 配置为 fork 进程而不是线程时是否使用它？
是的，因为 Python 仍然能够运行其他线程。仅仅因为您可能只使用单个线程并不意味着它可以避免 GIL，因为单个线程可以启动后台线程。
如果我们将 mod_wsgi 配置为：WSGIDaemonProcess example processes=5 threads=1。是否会使用 5 个 python 子解释器，每个解释器一个 GIL？