当我想部署Django应用程序时，有很多关于如何configurationnginx与uWGSI配合的教程。
但是为什么我需要在这个套件中使用nginx？ uWSGI本身可以服务于WSGI Python应用程序，它可以提供静态文件，也可以做SSL。 nginx能做哪些uWSGI不能做的？
你没有。
这就是简单的答案，无论如何 – 你不需要它。 uWSGI本身是一个有能力的服务器。
然而，像nginx这样的其他服务器已经存在了更长的时间，并且（可能无论如何）更安全，并且具有uWSGI不支持的附加function – 例如，改进了对静态资源的处理（通过任意组合的Expires或E-Tag头文件，gzip压缩，预压缩gzip等），可以显着减less服务器和networking负载; 此外，Django应用程序前面的服务器（如nginx）也可以实现对dynamic内容的caching，进一步帮助减less服务器负载，甚至有助于使用CDN（通常不适合dynamic内容）。 你甚至可以走得更远，在一个完全独立的服务器上有nginx，在处理静态内容本身时，将dynamic内容的请求反向代理到负载平衡的应用服务器集群。
例如，我的博客（虽然它是WordPress，它前面有nginx）被调整为caching24小时的post，并caching索引页面5分钟; 虽然我没有看到足够的stream量，但大部分时间都是如此，这可以帮助我的小VPS天气偶尔的波动，否则可能会把它击倒 – 比如当我的一篇文章被采摘时，大量的stream量其中有数千名追随者，其中许多人重新向其成千上万的追随者推特。
如果我运行一个“裸”的uWSGI服务器（假设它是一个Django站点，而不是WordPress），它可能已经站得住脚了，或者它可能已经崩溃和烧毁，使我错过了访问者。 在它之前有nginx处理负载可以真正帮助。
所有这一切，如果你只是运行一个小网站，不会看到很多的stream量，没有真正的需要nginx或其他任何东西 – 只要使用uWSGI自己，如果这是你想要做的。 另一方面，如果你会看到很多的交通…好吧，你仍然可能想要uWSGI，但你至less应该考虑一下前面的东西来帮助加载。 事实上，你应该真正负责testing不同的configuration与完成的网站，以确定哪些工作最适合你在你的预期负载，并使用任何最终的存在。
国际海事组织，如果你把你的网站，而不是实验室，你可能会看到不同之处。
想象一下来自另一个国家的networking速度较低的用户打开networking浏览器访问您的网站。 uWSGI将在一个线程中处理该Http连接。 由于networking速度低，该线程可能花费相当长的时间来等待完整的Http请求。 如果你的线程池大小为100，想象100个这样慢的用户，会发生什么？ 没有空闲线程来处理其他Http请求。
但是对于Nginx而言，情况完全不同。 Nginx是在“反应堆模式”中devise的。 你可以谷歌“反应堆模式”，看看它是如何工作的。 总之，慢速连接不会影响它来处理其他Http请求。