我在一些 Django 项目的生产环境中使用nginx + fastcgi(manage.py runfcgi ...)。很多人建议使用nginx + gunicorn。使用 gunicorn 而不是使用 Django 的 fastcgi 服务器有什么好处？
【问题讨论】：
标签： django deployment fastcgi gunicorn
我只是告诉你为什么需要使用类似 WSGI 的服务器 :) 但是如果你觉得使用 fcgi 很舒服 - 就使用它
简答：WSGI（作为协议）很酷，因为its native
或者如果“你需要更深入”(c)
下一个问题“FastCGI 与类似 WSGI 的服务器？”
这里有一些答案：
关于 gunicorn、uWSGI 和 cherokee、nginx。不要混合它们！
nginx 是一个网络服务器，可以处理 http 请求并将其发送到 WSGI 后端。 （但首先它对于静态内容处理非常快。） WSGI 后端处理你的 django 应用程序。
关于 cherokee，我认为它处理与 nginx 相同的任务，但我不使用它。
gunicorn，uWSGI 是 WSGI 后端，它使用 django 应用程序运行线程并执行many other tasks
嗯，gunicorn say那个
作为仅在类 Unix 平台上运行的服务器，unicorn 与 Unix 哲学紧密相连，即做一件事并（希望）把它做好。尽管使用 HTTP，unicorn 严格来说是一个后端应用服务器，用于运行基于 Rack 的 Ruby 应用程序。
我为我的 django 应用练习 nginx（来自 nginx.org repos 的最新稳定版）+uWSGI（来自 Debian 稳定版） - 完美运行 :)
2012 年 5 月 18 日编辑
链接到 2010 年主题并比较 fcgi gunicorn uWSGI
fcgi（线程）640 r/s
fcgi（prefork 4 处理器）240 r/s (*)
gunicorn（2 名工人）1100 转/秒
gunicorn（5 名工人）1300 转/秒
gunicorn（10 名工人）1200 r/s (?!?)
uwsgi（2 名工人）1800 转/秒
uwsgi（5 名工人）2100 转/秒
uwsgi（10 名工人）2300 转/秒
（* 这让我的电脑在通过屋顶时作为 CPU 异常缓慢）
【讨论】：
runfcgi 命令实际上是基于flup，因此使用了WSGI。一个更好的问题是flup vs. uwsgi或flup vs. gunicorn。
flup vs. uwsgi vs. gunicorn 赢得了uWSGI。我会尽快提供一些证据。
正如 b1- 所说，WSGI 是原生的（看看this post）。
另外，this post 也有类似的问题。
从我个人的角度来看，前段时间我一直在使用Nginx + uwsg in vhost mode 在我的服务器上运行各种项目。
【讨论】：