我们渴望使用基于django的应用程序的nginx + uwsgi，因为我们想尝试更新的解决scheme，并且听说nginx比apacheless资源密集型。
在从Django的创build者之一读到关于Quora上的apache的一些观点之后：
http://www.quora.com/What-web-server-suits-Django-best
I'm still a big fan of a stripped down Apache+mod_wsgi running behind nginx. Nginx handles static files, gzip, trickling to slow clients, load balancing and having a configuration language that's actually pleasant to work with. Apache just sits there serving up dynamic Python pages via mod_wsgi, using the shortest possible config.The reason I like Apache for this is I don't need to babysit the process at all, unlike if I was using FastCGI or running a separate Python app server. 我不打算为不同的目的设置2个Web服务器，只有nginx独自完成django的所有工作和uwsgi工作，会更开心。 我有几个问题：
什么是“没有必要保姆的过程”呢？ 与apache + mod_wsgi相比，nginx + uwsgi是否需要额外的努力？
据说Nginx对uwsgi有内置的支持，而不是对gunicorn，这是什么意思？
“保姆”部分是关于手动启动uWSGI / gunicorn进程（通过监视器，监视器或简单rc脚本等工具）。
一年多以前，uWSGI解决了uWSGI Emperor的“问题”，它将以一种非常简单的方式为你保存实例（只要将configuration文件放在dir中）。 因此，一个设置需要一个启动脚本的nginx和一个阿帕奇，而另一个需要一个nginx和一个为uWSGI皇帝（所以我们是2：2）。
关于nginx中的uwsgi支持，它与'uwsgi协议'有关，而不是uWSGI应用服务器。 这是一个比http更简单的传输方式，所以它可以带来一些性能上的好处，并增加一些特定的function（比如直接传递WSGI vars）。 你不是被迫使用uwsgi协议，你可以简单地以http模式启动uWSGI（如gunicorn），并通常代理它。
话虽如此，考虑到目前的uWSGI python-codebase与mod_wsgi非常相似（mod_wsgi的作者帮助了很多修复uWSGI python的bug），所以如果你不需要特定的uWSGI特性，一个真正精简的Apache + mod_wsgi。