为啥要使用nginx服务器？？

Posted 2023-05-04

1、nginx是web服务器的一种，除了可以缓存静态文件(html,js,css...)之外，还有别的功能吗？nginx这个缓存功能不要，直接从tomcat服务器上返回不是一样可以吗？用nginx和不用nginx区别在哪里？
2、网上都说nginx性能好，内存占用少而且处理的并发连接数可以上万，我想问，就是性能再好，并发数再高，最后不还得转发给应用服务器(如tomcat服务)吗？如果用nginx做负载均衡，那么一万的并发请求可以负载到不同的应用服务器上，但是我观察通常情况下都不用nginx做负载均衡，而是使用硬件负载均衡器做负载更快，那这样的话，nginx收到的一万个并发请求全部转发给应用服务器，那么这个请求的响应速度最终不是还得取决于应用服务器吗？而且能不能接受一万的并发也得取决于应用服务器，跟nginx有毛关系啊，它只不过中间转了一下，不用也罢，他们说的nginx的高性能在哪里呢？？？网上把nginx都夸到天上去了，究竟是什么原因，非要用nginx？？？

这里做了些基准测试表明nginx打败了其它的轻量级的web服务器和代理服务器，同样也赢了相对不是那么轻量级的产品。

有人说这些基准测试是不准确的，因为在这样那样的环境下，做的比较不一致。我倾向同意基准测试只是告诉了我们其中一部分情况，你能做的是消除偏见（有人见过所有人都同意一个基准测试是公平的吗？我是没见过。）

不管怎样，这篇文章不是做基准测试来让人们争论（如果你喜欢，可以在Google上找到那样的文章），相反，下面的引述来自人们在现实世界中使用Nginx，在真实的负载下，服务于真正的应用和网站。

引述

我们投资的一些公司把web平台切换到Nginx后，可以显著的解决扩展问题。Nginx明显有效的实现了今天互联网上最大网站数量的增长。

– Thomas Gieselmann, BV Capital.

我
对今天运行网站的所有人的建议是，想打破性能限制就研究下能否使用Nginx。CloudFlare去年在一个相对较小的基础设施上已经扩展到可以处理每
月超过150亿的浏览量，很大程度上是因为Nginx的扩展性。我的经验表明切换到Nginx可以最大限度的利用现代的操作系统和现有的硬件资源。

– Matthew Prince, CloudFlare的联合创始人和CEO

Apache和Nginx都有能力提供每秒钟庞大的请求服务，但是随着并发数量的增加，Apache的性能开始下降，然而Nginx的性能几乎不会下降。

这里最好的一点是：因为Nginx是基于事件的，它不用为每个请求产生新的进程或线程，所以它的内存使用很低。在我的基准测试中，它的内存使用坐落在2.5M，Apache使用得更多。

– WebFaction

针
对Nginx v0.5.22 and Apache
v2.2.8我用ab（Apache的基准测试工具）跑了一个简单的测试。在测试过程中，我用vmstat和top检测系统。结果表明在提供静态内容
时，Nginx做得比Apache好。两个服务器都在并发数100时表现最佳。Apache使用4个工作进程（线程模式），30%的CPU和17MB的内
存，每秒钟处理6,500次请求。Nginx使用一个工作进程，15%的CPU，1MB内存，每秒钟处理11,500次请求。

– Linux Journal

Apache好比是微软Word，它有100万个选项，但是你只需要其中6个。Nginx就处理那6项任务，但处理其中5项任务时速度比Apache快50倍。

– Chris Lea

我现在使用Nginx在单一服务器上处理每天超过数千万（也就是每秒钟几百次）的反向代理HTTP请求。在负载高峰期，它消耗大约15MB的内存和10%的CPU，在我的特定配置下（FreeBSD 6）。

在同样的负载下，Apache表现大跌（在大约使用1000个进程后，上帝知道使用了多少内存），Pound表现大跌（如此多的线程，所有的线程栈会消耗400MB以上的内存），还有Lighttpd每小时泄露20MB以上内存（使用更多CPU，但不显著）。

– Bob Ippolito in the TurboGears mailing list, 2006-08-24

我们现在使用Nginx 0.6.29的upstream hash模块为我们需要的Varnish代理提供静态杂凑。我们通常处理8-9千次请求/秒，大约1.2Gb/秒数据在几台Nginx服务器间传输，而且还有很大的成长空间。

– WordPress.com

直到今天，我们一直使用Pound来解决Justin.tv 的负载均衡。它一直使用20%的CPU，在高峰期会达到80%。在极高的负载下，它偶尔会崩溃。

我们只是切换到了Nginx，负载马上就降到了大约3%的CPU使用。我们的页面感觉更快了，尽管这可能是我的错觉。不仅它的配置文件格式容易理解和配置，而且还提供了完整的web服务器功能。我们再也没有遇到尖峰期了，而且我怀疑现有的性能会彻底打败Pound。

– Emmett Shear

我们使用Nginx作为主要的软件用于一个免费的托管平台，我已经在Nginx中开发了一个特定的模块用于banner潜入和统计计算，现在我们的中央服务器可以处理大约150-200Mbit/s高度分散的http流量（所有的文件都很小）。

我认为这是非常好的结果。因为在同样的服务器上面Apache不管怎么优化，甚至都不能处理60-80Mbit/s。

– Alexey Kovyrin

前
阵子，我们把我们的前端IMAP/POP代理从perdition切换到了nginx…，现在我们又使用nginx来做前端web代理服务器…。最终的结
果是，现在的每台前端代理服务器可以保持超过10,000并发（IMAP, POP, Web &
SMTP）连接（其中很多还是SSL），仅仅只使用了大约10%的CPU。

– FastMail.fm blog

最近，我们的静态内容服务器切换到了Nginx，无疑这是这么多年来我印象最深刻的一款web服务器。我们运行在一台配有8G内存的机器上，但是nginx进程只使用了可笑的1.4Mb。

– Philip Jacob

我们已经用nginx取代了Squid（反向代理）+Apache的方案，平均负载和CPU使用一样降低了一半。另外我们的基准测试表明新的配置每秒钟可以处理的请求数是旧配置的2-3倍。

– HowtoForge

我们用一些CMS系统（ Wordpress, Drupal, Joomla, TYPO3等）做了基准测试，结果是Nginx提供网页的速度比Apache快了50%，同时nginx每秒钟处理的请求数(RPS)是Apache的177%。追问

答非所问

参考技术A 我们大多数的客户在他们的服务器上使用Apache作为Web服务器，尤其是部署在一个基于php系统的前端并且使用mod-PHP。鉴于扩张性和性能方面的原因，我们通常会建议他们改用Nginx和FPM。

Apache是非常强大的Web服务器，模块化结构，也是Web服务端的鼻祖。除了捆绑一些其他的工具外，Apache已经成为了世上最广泛部署的开源系统，直到最近，世界上大多数网站仍运行着Apache系统。

但是，Apache并不是完美的，并且不再适合大规模系统。为什么？因为他的进程模式虽然简单而灵活，但并不适合大规模尤其是当要处理像PHP这种需要占用大量内存应用程序代码时。

一个典型的网络应用服务器由两部分组成。客户端连接部分负责用户浏览器与HTTP连接，保持长时间的TCP/IP协议，通常是1到2分钟。对于一个大型的系统，服务器可能要同时承担和处理数以万计的并发连接。

这直接与Apache只有 500条进程即500个HTTP连接的处理能力上限相冲突。而现今的浏览器让这个问题更加严重, 因为现在的浏览器平均每个主机会打开六个网站链接（几年前是两个网站链接）。所以当超过100个用户同时访问时，Apache就已经满负荷了。

第二部分是应用程序处理部分，这部分承担了代码运算。在大多数系统中，这部分工作是最消耗RAM和CPU资源的，因此进程数量必须被严格限制，通常是大约每1GB的内存10个进程，或者每个CPU核心两个进程。因此一台4GB RAM、16内核的服务器最多只能运行32个应用程序进程。

但是，问题的关键是，Apache直接连接前端客户端通讯组件与后端应用程序进程组件。如此一来，前端部分往往保持长时间的连接，常常达到几分钟，这导致后端部分将持续消耗内存和CPU资源。目前还没有直接的方法能够在大型系统中找到前后端服务的平衡，因此他们必须被分离开来。

目前有两个主要的解决方法。第一个方法，也是现有系统上最容易的方法，就是在Apache前端安装负载均衡服务器或者Nginx来处理客户端连接部分。负载均衡服务器，像HAProxy或者Nginx能轻松处理成千上万条并发的连接，并使Apache能够真正的仅作为后端应用程序工作，来处理32个或是更多的进程。

第二种方案，也是最通用的办法就是用Nginx替换Apache，同时使用PHP-PFM作为应用服务器。就像之前所提到的，这将分割前端客户端通信部分和后端应用程序部分。Nginx处理HTTP通讯协议，同时FPM处理后端应用程序部分，和那32个进程进行交互。

然而这几种方法仍然还存在一些问题，主要是如何加载服务器的RPC调用，以及如何释放已经完成的RPC调用。 这两个问题都会在其他的博客中加以详解。

另外，只使用Nginx的解决方法会给那些严重依赖于Apache功能的应用程序带来问题，尤其是特别依赖rewrite rules, .htaccess, 或者mod_security等一些可选组件的应用程序。在这种情况下，在Apache前端增加安装Nginx是最好的方法。

通常来说，所有新的系统都应该使用Nginx和PHP-FPM来部署。这能提供高性能增长特性，并且是平衡用户和内存，CPU资源的最佳选择。已存在的系统可以在前端使用Nginx或者HAProxy以达到同样的效果，以便在当今现代网络环境中为用户提供更优质的服务。

为啥使用 Nginx 运行 Flask 需要 WSGI 包装器？

【中文标题】为啥使用 Nginx 运行 Flask 需要 WSGI 包装器？

【英文标题】：Why does running Flask with Nginx require a WSGI wrapper?为什么使用 Nginx 运行 Flask 需要 WSGI 包装器？

【发布时间】：2015-01-16 13:44:37

【问题描述】：

因此，从 Python/Flask 文档中，他们都建议不要将 Flask Web 服务器作为生产 Web 服务器运行，这是有道理的。我的问题是，我是否能够在 Nginx 服务器上运行我的 Flask 应用程序？为什么互联网上的所有指南都建议将 Flask 包裹在 uWSGI、Tornado 或其他一些 WSGI 服务器上？ WSGI 是什么意思？ Flask WGSI 不兼容吗？

我特别迷茫，因为here，第一反应说：

Apache 和 Nginx 都是 HTTP 服务器。它们可以提供静态文件，例如 （.jpg 和 .html 文件）或动态页面（例如用 PHP 或 Python 等语言编写的 Wordpress 博客或论坛）。

但是this 帖子状态：

Nginx 是一个网络服务器。它提供静态文件，但无法执行和托管 Python 应用程序。 uWSGI 填补了这一空白。

我的应用程序由一个服务器（例如：uWSGI）然后另一个服务器（例如：Nginx）处理似乎效率低下。

【参考方案1】：

Nginx 是一个 Web 服务器，它关注的是 Web 服务器的东西，而不是如何运行 Python 程序。 uWSGI 是一个应用服务器，并且知道如何用 Python（以及现在的其他语言）说 WSGI。 Nginx 和 uWSGI 都使用 uWSGI 协议，这是一种在 UNIX 套接字上的高效协议。

Nginx 处理来自/响应外部世界的 http 请求（可能是负载平衡、缓存等）。您的 Flask 应用程序处理 WSGI 请求/响应。 uWSGI 知道如何启动您的应用程序（可能使用多处理和/或线程）并弥合 HTTP 和 WSGI 之间的差距。

除了 Nginx 之外还有其他的 HTTP 服务器，除了 uWSGI 之外还有其他的 WSGI 服务器，但是它们都使用相同的工作流程：HTTP 服务器传递给 WSGI 服务器，WSGI 服务器管理你的应用程序进程并返回给 HTTP 服务器。

此设置称为reverse proxy。它允许每个工具做它擅长的事情，而不用关心过程的其他部分。没有什么特别低效的，直到你真正大规模规模。

【参考方案2】：

嗯，WSGI 是 Python 应用程序和 Web 服务器之间的接口规范。 uWSGI（简单地说）是用 C/C++ 编写的该规范的实现。只需提供一个入口点，您就可以在“严肃的”网络服务器（如 nginx）上运行几乎任何应用程序：

def application(env, start_response):
    start_response('200 OK', [('Content-Type','text/html')])
    return ["Hello World"]

然后像这样运行它：

uwsgi --http :9090 --wsgi-file file_with_the_code_above.py

当然，您可以返回任何您想要的东西，而不是 ["Hello world"]。请参阅http://uwsgi-docs.readthedocs.org/en/latest/WSGIquickstart.html 了解更多信息。