当我想部署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请求。