Nginx是一款轻量级的Web服务器、反向代理服务器，由于它的内存占用少，启动极快，并发能力强，在互联网项目中广泛应用。

用途一样，部署方式不尽相同，有的企业数据敏感，Nginx会运行在本地环境，这个时候可以选择裸机或者虚拟机部署。但随着公共云呈爆炸式增长，这时企业也在采用混合云，在公有云和本地（例如在私有数据中心）中运行工作负载。

公有云一般采用Kubernetes，它可以轻松部署基于容器的应用程序。但是，在 Kubernetes 上运行的生产应用程序需要经过验证的生产级应用程序交付解决方案。NGINX Ingress Controller 将值得信赖的 NGINX 开源和 NGINX Plus 软件负载均衡器与自动化配置相结合，以确保 Kubernetes 集群中的应用程序可靠、安全且高速地交付。

为了确定满足您的性能和扩展需求的最佳且最实惠的本地解决方案，我们提供了一个性能测试指标，用于比较不同环境中的 NGINX 性能。

测试方法

我们使用了两种架构来衡量和比较 NGINX 在不同环境下的性能。对于每个架构，我们运行了单独的测试集来衡量两个关键指标，每秒请求数 (RPS) 和每秒 SSL/TLS 事务数 (TPS) 。

传统的本地架构

NGINX 是两种条件下的被测系统 (SUT)：在裸机和虚拟机环境中运行。在这两种情况下，四个Ixia客户端生成请求，NGINX 负载均衡到四个 Ixia Web 服务器。Web 服务器响应每个请求返回一个 128 字节的文件。

我们使用以下软件和硬件进行测试：

• Ixia 客户端和 Web 服务器使用Axia Xcellon-Ultra™ XT80v2应用上的IxLoad软件进行部署。

• 对于这两种情况下的 SUT，CentOS 7 是配备英特尔 NIC 的 PowerEdge 服务器上的操作系统。

• 虚拟机程序是VMWare ESXi 7.0.0 版。

这是nginx.conf配置：https://gist.github.com/nginx-gists/b52ea661c2f205fa0d519d66fd65a34c

Kubernetes 架构

SUT 是运行在 Rancher Kubernetes Engine (RKE) 裸机平台上的 NGINX Ingress Controller（基于 NGINX Open Source）。四个 Ixia 客户端生成请求，NGINX Ingress Controller 将这些请求定向到后端 Kubernetes 部署，这是一个 Web 服务器，它返回一个 1KB 的文件以响应每个请求。

我们使用以下软件和硬件进行测试：

• 使用 IxLoad 软件部署在Axia Xcellon-Ultra XT80v2应用上的 Ixia 客户端生成请求。不需要 Ixia Web 服务器，因为我们是在 Kubernetes 环境中测试工作负载。

• SUT 和托管后端应用程序的节点的操作系统都是 CentOS 7。SUT 和后端应用程序运行在-  两个带有 Intel NIC 的独立 PowerEdge 服务器节点上。

• NGINX Ingress 版本是 1.11.0。

这是裸机 RKE 上部署 NGINX Ingress Controller配置文件：https://gist.github.com/nginx-gists/b52ea661c2f205fa0d519d66fd65a34c

收集的指标

我们运行测试来收集两个性能指标：

• 每秒请求数 (RPS)  – NGINX 每秒可以处理的请求数，在固定时间段内的平均值。在这种情况下，Ixia 客户端的请求使用了http方案。

• SSL/TLS 每秒事务数 (TPS)  – NGINX 每秒可以建立和服务的新 HTTPS 连接数。在这种情况下，Ixia 客户端的请求使用了https方案。我们使用具有2048 位密钥大小的RSA算法 。

Ixia 客户端发送了一系列 HTTPS 请求，每个请求都在一个新连接上。Ixia 客户端和 NGINX 执行 TLS 握手以建立安全连接，然后 NGINX 将请求代理到后端，请求完成后连接关闭。

性能分析

表格报告了在传统架构和 Kubernetes 架构中 NGINX 可用不同数量的 CPU 实现的 RPS 和 SSL TPS 数量。

传统的本地架构

NGINX 在裸机上的性能呈线性增长，直到可用 CPU 数量达到 8 个。我们无法测试更多的内核，因为当有 8 个或更多内核时，Ixia 客户端无法生成足够的请求来使 SUT 饱和（达到 100% CPU 利用率）。

我们发现，与裸机相比，虚拟化使性能下降了很小但可以衡量的程度。虚拟机程序中的 CPU 指令比裸机上的相同指令需要更多的时钟周期，这会导致额外的开销。

Kubernetes 架构

当我们将内核数量扩展到 8 个时，Kubernetes 中 NGINX Ingress Controller 的性能会线性增加。

将下表中的结果与传统架构的结果进行比较，我们发现在 Kubernetes 中运行 NGINX（作为 NGINX Ingress Controller）会显着降低网络绑定操作（如服务请求）的性能（以 RPS 衡量）。这是由于用于连接到其他服务的底层容器网络堆栈。

另一方面，我们发现传统环境和 Kubernetes 环境对于 CPU 密集型操作（如 SSL/TLS 握手（以 TPS 衡量））之间没有性能差异——实际上，Kubernetes 中的 TPS 稍好一些。

此外，当我们启用超线程 (HT) 时，我们看到 TPS 大约增加了 10%。

结论

以下是一些关键要点，可帮助您了解您的工作负载最适合运行的环境，以及对所选环境的性能影响。

• 如果您的应用程序基础设施正在执行网络绑定操作（在我们的测试中以 RPS 衡量），那么在传统的裸机环境中运行 NGINX 是性能的最佳选择。由于环境中使用的底层容器网络堆栈，在 Kubernetes 中运行 NGINX Ingress Controller 会导致网络绑定操作的性能成本最高。

• 虚拟机管理程序为网络和 CPU 密集型操作引入了少量但可衡量的性能成本（RPS 约为裸机价值的 80%）。

• 如果您的应用程序基础架构正在执行 CPU 密集型操作（在我们的测试中以 TPS 衡量），则 NGINX 在传统环境和 Kubernetes 环境中几乎没有性能差异。

• 在我们的测试中，超线程将可并行化 CPU 密集型操作（如加密）的性能提高了大约 10%。

原文链接

1. https://www.nginx.com/blog/comparing-nginx-performance-bare-metal-and-virtual-environments/?utm_source=thenewstack&utm_medium=website&utm_campaign=platform#Metrics-Collected

2. https://www.nginx.com/resources/datasheets/nginx-ingress-controller-kubernetes/

3. https://www.nginx.com/blog/comparing-nginx-performance-bare-metal-and-virtual-environments/?utm_source=thenewstack&utm_medium=website&utm_campaign=platform#Metrics-Collected

4. https://gist.github.com/nginx-gists/b52ea661c2f205fa0d519d66fd65a34c

5. https://www.vmware.com/products/esxi-and-esx.html

推荐

NAT 穿透是如何工作的：技术原理及企业级实践

DNS 故障诊断及问题分析示例

---

随手关注或者”在看“，诚挚感谢！