官方数据，测试NGINX和NGINX Plus 商业版HTTPS SSL证书加密流量访问，Web服务器的并发性能
官方数据，测试NGINX和NGINX Plus 商业版HTTPS SSL证书加密流量访问，Web服务器的并发性能本帖主要以NGINX Plus商业版为基准进行测试，NGINX 官方不开源的商业版，性能更高，并且多了web网页管理NGINX核心配置文件的管理界面 还有一些高级功能。
==================以下内容为原文=====================================
我们都知道，性能对网站的成功至关重要。没有人想使用慢速网站。
自2004年首次开源以来，NGINX一直是高性能网站的代名词。世界排名前100,000的网站中有63％，全球超过3.19亿个网站现在由NGINX提供支持。但NGINX实际上表现如何？哪些硬件配置能以合理的价格获得最佳性能？
为了回答这些问题，我们以两种配置进入实验室和经过性能测试的NGINX：作为反向代理和Web服务器。我们在NGINX Plus裸机服务器大小指南中发布了反向代理性能数据，并详细介绍了如何在我们的博客NGINX Plus大小调整指南：我们如何测试中完成测试。
自从发布这些文章以来，我们收到了许多关于基础测试结果的更具体信息的请求。因此，在这篇博文中，我们提供了实时HTTP和HTTPS连接上每秒请求数（RPS）和每秒连接数（CPS）的详细性能数字。我们还在作为Web服务器运行的NGINX的50个专用通道上呈现HTTP吞吐量。结果适用于开源NGINX软件和NGINX Plus。
我们希望这些信息可以帮助您确定处理Web应用程序当前和未来流量所需的硬件规格，同时考虑您的预算和性能需求。
测试概述
我们使用的测试设置几乎与NGINX Plus大小调整指南：我们如何测试中的设置完全相同，除了客户端和Web服务器之间没有反向代理。所有测试都是使用两个独立的机器在一个简单，平坦的第2层网络中通过双40-GbE链路连接在一起完成的。
https://www.nginx.com/wp-content/uploads/2017/08/Testing-web-server-performance-image-1.png
我们在客户端和Web服务器之间使用了50个端到端连接来测试NGINX性能
为了模拟测试中不同数量的CPU，我们改变了NGINX工作进程的数量。默认情况下，开始执行的NGINX工作进程数等于NGINX运行的机器中可用的CPU数。您可以通过更改/etc/nginx/nginx.conf文件中的worker_processes指令值并重新启动NGINX服务来更改执行NGINX工作进程的数量。
对于使用HTTPS保护客户端流量的测试，我们使用以下加密参数：
ECDHE-RSA-AES256-GCM-SHA384密码
2,048位RSA密钥
完美的前向保密，如密码中的ECDHE所示
OpenSSL 1.0.1f
使用的硬件
我们使用以下硬件在客户端和Web服务器上进行测试：
CPU：双路 Intel（R）Xeon（R）CPU E5-2699 v3 @ 2.30 GHz，36个实际（72 HT）内核
网络：双网卡 Intel XL710 40 GbE QSFP +（rev 01）
内存：16 GB
使用的软件
我们使用以下软件进行测试：
wrk在客户端计算机上运行的4.0.0版生成了NGINX代理的流量。我们按照这些说明安装了它。
开源NGINX软件的1.9.7版在Web服务器上运行。我们根据这些说明从nginx.org的官方存储库安装了它。
Ubuntu Linux 14.04.1在客户端和Web服务器上运行。
绩效指标与分析
我们从测试中获得了以下性能数据。
每秒请求数
每秒请求数（RPS）衡量处理HTTP请求的能力。每个请求都从客户端计算机发送到NGINX Web服务器。测试是针对未加密的HTTP和加密的HTTPS流量进行的。
按照性能测试的常规做法，我们使用了四种标准文件大小：
0 KB模拟“空”HTTP请求或响应，没有伴随数据，例如302错误代码。
1 KB大小与小型CSS或JavaScript文件的大小相当，或者是非常小的图像，例如小图标。
10 KB近似更大的代码文件，更大的图标和小图像文件。
100 KB表示大型代码文件和其他较大的文件。
发出小型HTTP请求每秒可以提供更多请求，总吞吐量更低。发出大型HTTP请求可以减少每秒的请求次数和吞吐量，因为单个请求会启动大量文件传输，需要相当长的时间才能完成。
HTTP请求的RPS
下表和图表显示了不同数量的CPU和不同请求大小的HTTP请求数，以千字节（KB）为单位。
CPU的0 KB1 KB10 KB100 KB
1145551740915468433125
224929313146610206962554
454306126126920784888691
8104842152474539215191640
16200184697238266392191623
323019182131636277456791640
363298511130935876474491655
https://www.nginx.com/wp-content/uploads/2017/08/NGINX-HTTP-RPS.png
大型HTTP请求（例如测试中的10和100 KB大小）是碎片化的，需要更长的时间来处理。结果，图表中用于较大请求的线具有更平坦的斜率。
在权衡预算与性能的选项时，需要注意的一个有趣的事情是，当您通过16个CPU时，线的斜率会发生变化。具有32个CPU的服务器执行与具有36个CPU的服务器相同或更好，用于1 KB和10 KB请求大小。资源争用最终会超过添加更多CPU的积极影响。这表明，对于4到8个核心的HTTP流量的常见服务器配置可能会因为添加CPU总数高达16个而受益，而使用32个则少得多，并且移动到36时几乎没有或没有任何好处。但是，总是如此关于测试，您的里程可能会有所不同......
用于HTTPS请求的RPS
对于相同的配置裸机硬件，HTTPS RPS低于HTTP RPS，因为保护机器之间传输的数据所需的数据加密和解密在计算上是昂贵的。
尽管如此，英特尔架构的持续进步 - 导致服务器具有更快的处理器和更好的内存管理 - 意味着与专用硬件加密设备相比，CPU绑定加密任务的软件性能不断提高。
虽然HTTPS的每秒连接大约比16-CPU标记处的HTTP少四分之一，但是以添加CPU的形式“抛出硬件问题”比HTTP更有效 - 一直到36 CPU，用于更常用的文件大小。
CPU的0 KB1 KB10 KB100 KB
17156140207233084830
215132585139486549871
43246541783959680819355
864721335957619881838900
16126299969032938386077427
322197336120795969280490430
362175945123962473374589842
每秒连接数
每秒连接数（CPS）衡量NGINX创建新TCP连接到发出请求的客户端的能力。客户端在新连接上发送一系列HTTP或HTTPS请求。NGINX解析请求并为每个请求发回0字节响应。请求满足后关闭连接。
注意：此测试的HTTPS变体通常称为每秒SSL事务 （SSL TPS）。
HTTP请求的每秒连接数
表和图表显示了跨不同数量的CPU的HTTP请求的每秒连接数（CPS）。
CPU的每秒连接数（CPS）
134344
254368
4123164
8194967
16255032
32261033
36257277
https://www.nginx.com/wp-content/uploads/2017/08/HTTP-CPS.png
该图类似于 f（x）=√x，其中x是运行的CPU数。至于RPS，当我们将CPU的数量从32个增加到36个时，CPS增长趋于约16个CPU，并且性能略有下降（此处为CPS）。
HTTPS请求的每秒连接数
表和图表显示HTTPS请求的每秒连接数（CPS）。由于时序限制，我们没有使用32个CPU运行测试。
CPU的每秒连接数
1428
2869
41735
83399
166676
2410274
3610,067
https://www.nginx.com/wp-content/uploads/2017/08/SSL-TPS.png
我们观察到CPS增加的速度越快，我们添加的CPU就越多。图形线在24个CPU处变平。对于SSL，抛出问题的硬件效果很好。
吞吐量
这些测试测量NGINX能够在180秒内维持的HTTP请求（以Gbps为单位）的吞吐量。
CPU的100 KB1 MB10 MB
1134868
2206971
4456771
8506872
16486671
32486671
36486671
https://www.nginx.com/wp-content/uploads/2017/08/Throughput.png
吞吐量与客户端计算机发出的HTTP请求的大小成比例。当文件大小较大时，NGINX会获得更高的吞吐量，因为给定的请求会导致更多数据的传输。但是，性能在大约8个CPU处达到峰值; 对于吞吐量大的任务，更多不一定有益。
杂项说明
关于测试和结果的一些其他说明：
我们测试的CPU上提供了超线程，这意味着可以运行额外的NGINX工作进程来使用超线程CPU的全部容量。我们没有为这里报告的测试启用超线程，但我们确实看到在单独的测试中使用超线程提高了性能。最值得注意的是，超线程将SSL TPS提高了约50％。
这里给出的数字是OpenSSL 1.0.1。我们还使用OpenSSL 1.0.2进行了测试，并且性能提升了2倍。OpenSSL 1.0.1仍然被广泛使用，但我们建议转向OpenSSL 1.0.2，以获得更好的安全性和更好的性能。
我们还测试了椭圆曲线加密（ECC），但这里给出的结果使用RSA。对于加密，RSA仍然比ECC广泛使用，尽管ECC通常部署用于移动，其中功耗的效率是必要的。与标准RSA证书相比，我们看到ECC的性能提高了2到3倍，我们建议您考虑实施ECC。
迁移到OpenSSL 1.0.2并转向ECC的组合可能会带来非常强大的性能提升。此外，如果您当前使用4 CPU或8 CPU服务器，并且移动到16个CPU - 甚至32个CPU，用于SSL - 正如我们在此处提供的测试结果所暗示的那样，您可能会实现真正显着的改进。
结论
我们已经分析了实时HTTP和HTTPS连接上的RPS和CPS的性能测试结果，以及50个专用通道上的HTTP吞吐量。根据您的预算和性能需求，使用此博客中的信息可帮助您确定处理网站当前和未来流量所需的硬件规格。
文章出处：https://www.nginx.com/blog/testi ... x-plus-web-servers/
==================以上内容为原文=====================================
总结，你信吗
nginx能有这么高性能？每秒QPS并发能达到400，你信吗？
双路E5-2699 v3
2*40GE网卡
而且测试用的不开源的plus商业版←
页:
[1]