sudotty
commented
4 years ago 在过去的几年里，我与一些合作伙伴合作，他们对NGINX Plus的性能非常关注。谈话通常从他们难以达到我们公布的性能基准开始。这种挑战通常是由于合作伙伴直接跳到一个固定的用例，例如使用现有的SSL密钥或针对非常大的文件有效载荷，然后看到NGINX Plus的性能低于标准。
在一定程度上，这是预期的行为。我总是喜欢向合作伙伴解释，作为一个软件组件，NGINX Plus在处理最基本的HTTP用例时，可以在任何可用的硬件上以接近线速的速度运行。不过，为了达到我们公布的特定用例的数据，NGINX Plus通常会从改变配置以及调整低级操作系统和硬件设置中获益。
迄今为止，在每一个案例中，我们的合作伙伴都能够通过非常独特的用例实现理论性能数字，只需关注需要配置以匹配其用例的操作系统和硬件设置的组件，以及NGINX Plus如何与这些组件互动。
多年来，我已经编制了这个NGINX配置、操作系统和硬件技巧、诀窍和调整的列表。它旨在帮助我们的合作伙伴和客户针对其特定的使用案例实现开源NGINX软件和NGINX Plus的更高性能。
本文档只是对可能影响性能的配置设置子集的指导；它不是一个详尽的列表，也不一定适合在您的环境中更改下面讨论的每项设置。
注意：自最初发布以来，我们已经修改了这篇博客文章，并正在进一步审查，以使其尽可能强大。请在下面的评论中添加您自己建议的修改和补充；我们会将我们能做的纳入博文中。
调优流程
在处理性能调整问题时，我通常推荐以下工作流程。
在最通用的HTTP用例中测试NGINX Plus性能。这允许您为您的特定环境设置正确的基准线。
确定您的特定用例。例如，如果您的应用程序需要上传大文件，或者您正在处理高安全性的大SSL密钥大小，请先定义最终目标用例。
为您的用例配置NGINX Plus，并重新测试，以确定您环境中的理论性能与用例的实际性能之间的差距。
每次调整一个设置，专注于最适用于用例的设置。换句话说，不要在添加新的NGINX指令的同时更改一堆systemctl设置。从小处着手，从最适用于你的用例的功能开始。例如，如果高安全性对你的环境至关重要，就先改变SSL密钥类型和大小。
如果更改不影响性能，则将设置恢复到默认值。当你在每个单独的更改中取得进展时，你会开始看到一个模式，即相关的设置往往会一起影响性能。这使您可以在以后根据需要一起调整的设置组中找到家。
需要注意的是，每一个部署环境都是独一无二的，都有自己的网络和应用程序性能要求。在生产中改变其中的一些值可能是不可取的。下面概述的任何配置调整的结果都会根据应用类型和网络拓扑而产生显著不同的结果。
由于NGINX在开源社区中根深蒂固，多年来许多人都对性能对话做出了贡献。在适用的情况下，我已经包含了外部资源的链接，以获得已经在生产中对这些解决方案进行了实战测试的人提供的具体性能调整建议。
调优NGINX配置
关于支持的值、默认设置以及每个设置支持的范围，请参考NGINX参考文档。
SSL
本节介绍了如何从OpenSSL和NGINX中删除缓慢和不必要的密码。
当SSL性能至关重要时，在环境中尝试不同的密钥大小和类型总是一个好主意，在用于提高安全性的较长密钥和用于加快性能的较短密钥之间找到特定安全需求的正确平衡。一个简单的测试是从更传统的RSA密钥转移到椭圆曲线密码学（ECC），它使用更小的密钥大小，因此在相同的安全水平下计算速度更快。
要快速生成自签名的ECC P-256密钥用于测试，请运行这些命令。
# openssl ecparam -out ./nginx-ecc-p256.key -name prime256v1 -genkey
# openssl req -new -key ./nginx-ecc-p256.key -out ./nginx-ecc-p256-csr.pem -subj '/CN=localhost'
# openssl req -x509 -nodes -days 30 -key ./nginx-ecc-p256.key -in ./nginx-ecc-p256-csr.pem -out ./nginx-ecc-p256.pem压缩
Gzip参数提供了对NGINX如何传送内容的细化控制，因此设置不正确会降低NGINX的性能。启用 gzip 可以节省带宽，改善慢速连接的页面加载时间。(在本地的合成基准中，启用gzip可能不会显示出与真实世界相同的好处。) 尝试以下设置以获得最佳性能。
- 只为相关内容启用gzip，如文本、JavaScript和CSS文件。
- 不要增加压缩级别，因为这会耗费CPU的精力，而吞吐量却没有相应的增加。
- 评估对不同类型和大小的内容启用和禁用gzip进行压缩的效果。 更多关于细粒度gzip控制的信息可以在NGINX gzip模块的参考文档中找到。
连接处理
有几个与连接处理相关的调整选项。请参考链接的参考文档，了解正确的语法、适用的配置块（http、服务器、位置）等细节。
- accept_mutex off - 所有工作进程都会被通知新的连接（在NGINX 1.11.3和更高版本以及NGINX Plus R10和更高版本中为默认）。如果启用，工作进程会轮流接受新的连接，我们建议保持默认值（关闭）。 我们建议保持默认值（关闭），除非您对应用程序的性能有广泛的了解，并且有机会在各种条件下进行测试，但如果新连接的数量较少，它可能会导致系统资源的低效率使用。在一些高负载的情况下，将该值改为开启可能会有好处。
- keepalive 128 - 启用从NGINX Plus到上游服务器的keepalive连接，定义每个工作进程缓存中保存的空闲keepalive连接的最大数量。当超过这个数量时，最近使用最少的连接将被关闭。如果没有keepalives，就会有更多的开销，而且连接和短暂端口的使用效率都不高。
对于HTTP流量，当你在上游块中包含该指令时，你必须在配置中包含以下指令，以便它们适用于所有代理流量到该上游组的位置块（你可以将它们放在单个这样的位置块中，在父服务器块中，或在http级别）。
- proxy_http_version 1.1 - NGINX Plus使用HTTP/1.1作为代理请求。
- proxy_set_header Connection "" - NGINX Plus从代理请求中剥离任何连接头。
官方文章