由于新冠疫情爆发，公有云的采用呈爆炸式增长的同时，企业也正积极拥抱混合云，即在公有云和本地（比如私有数据中心）同时运行工作负载。
这一混合方案使企业能够在最能满足其需求的环境中部署工作负载。例如，企业可以在本地环境中部署具有高度敏感数据的任务关键型工作负载，同时利用公有云运行仅需对核心网络基础架构进行有限访问的 Web 托管和边缘服务（如物联网）等工作负载。
当在本地运行工作负载时，您可以进一步选择是在裸机环境还是在虚拟（管理程序）环境中运行。为了帮助您确定最出色、最经济的本地解决方案来满足您对性能和扩展性的需求，我们提供了一份选型指南，比较了 NGINX 在这两种环境中的性能。
本文介绍了如何测试 NGINX 以得出选型指南中发布的数值。由于许多客户也将应用部署至 Kubernetes，因此我们还在 Rancher Kubernetes Engine (RKE) 平台上分步测试了 NGINX Ingress Controller，并阐述了（在我们“解决方案简介”中所述的）测试结果与在传统本地架构中运行的 NGINX 相比有何不同。
测试方法
W我们使用两种架构来测量和比较 NGINX 在不同环境中的性能。我们在每种架构中运行一系列不同的测试，以测量两个关键指标：每秒请求数 (RPS) 和每秒 SSL/TLS 事务数 (TPS) — 有关详细信息，请参阅下方“收集的指标”一节。
传统本地架构
NGINX 作为被测系统 (SUT) 在以下两种条件下进行了测试：运行于裸机和虚拟管理程序环境下。在这两种条件下，四个 Ixia 客户端都生成了请求，并通过 NGINX 负载均衡到四台 Ixia Web 服务器。这些 Web 服务器在响应每个请求时各返回了一个 128 字节文件。
我们使用以下软硬件进行了测试：
- 使用 Axia Xcellon-Ultra™ XT80v2 应用刀片上机上的 IxLoad 软件对 Ixia 客户端和 Web 服务器进行了部署。
- 对于这两种条件下的 SUT，PowerEdge 服务器上运行的操作系统是采用英特尔网卡的 CentOS 7。
- 虚拟管理程序为 VMWare ESXi 7.0.0 版本。
下载用于在测试环境中部署 NGINX 的 NGINX 配置文件。
Kubernetes 架构
SUT 是运行于 Rancher Kubernetes Engine (RKE) 裸机平台之上的 NGINX Ingress Controller（基于 NGINX 开源版）。四个 Ixia 客户端生成请求后，NGINX Ingress Controller 将其定向到后端 Kubernetes 部署 — 这台 Web 服务器在响应每个请求时各返回了一个 1-KB 文件。
我们使用以下软硬件进行了测试：
- 部署在装有 IxLoad 软件的 Axia Xcellon-Ultra XT80v2 应用刀片机上的 Ixia 客户端生成了请求。因为我们在 Kubernetes 环境中测试工作负载，所以无需使用 Ixia Web 服务器。
- 对于 SUT 和托管后端应用的节点，二者操作系统均为 CentOS 7。SUT 和后端应用在采用英特尔网卡的两个不同的 PowerEdge 服务器节点上运行。
- NGINX Ingress Controller 版本为 1.11.0。
下载用于在裸机 RKE 上部署 NGINX Ingress Controller 的 YAML 文件。
收集的指标
我们运行了测试来收集两项性能指标：
-
每秒请求数 (RPS) —— NGINX 每秒可处理的请求数（取固定时间段内平均值）。在这种情况下，来自 Ixia 客户端的请求使用的是 http 协议。
-
每秒 SSL/TLS 事务数 (TPS) —— NGINX 每秒可建立和支持的新 HTTPS 连接数。在这种情况下，来自 Ixia 客户端的请求使用的是 https 协议。我们使用了 2048 位 RSA 密钥加密和完全向前保密（PFS）。
Ixia 客户端通过新连接发送一系列 HTTPS 请求。Ixia 客户端和 NGINX 执行 TLS 握手以建立安全连接，然后 NGINX 将请求代理到后端。请求得到满足后连接关闭。
性能分析
下一部分中的表格提供了在传统架构和 Kubernetes 架构中搭载不同数量 CPU 的 NGINX 所实现的 RPS 和 SSL TPS 数量。
传统本地架构
NGINX 在裸机上的性能呈线性增长，直到可用 CPU 数量达到八个。我们无法测试更多数量的内核，因为当配备 8 个或更多内核时，Ixia 客户端无法生成足够的请求来让 SUT 达到饱和（CPU 利用率达到 100%）。
我们发现，与裸机相比，虚拟环境使性能稍有下降，但仍是可以明显看到的。较之裸机，在虚拟管理程序中运行 CPU 指令需要更多的时钟周期，这将产生额外的开销。
| 硬件成本 | CPU 内核数 | RPS – 裸机 |
RPS – 管理程序 |
SSL TPS – 裸机 |
SSL TPS – 管理程序 |
|---|---|---|---|---|---|
| $750 | 1 | 48,000 | 40,000 | 800 | 750 |
| $750 | 2 | 94,000 | 75,000 | 1,600 | 1,450 |
| $1,300 | 4 | 192,000 | 132,000 | 3,200 | 2,900 |
| $2,200 | 8 | 300,000 | 280,000 | 5,200 | 5,100 |
Kubernetes 架构
当我们将内核数量扩展到八个时，Kubernetes 中 NGINX Ingress Controller 的性能呈线性增长。
通过将下表中的结果与传统架构的结果进行比较，我们发现，在 Kubernetes 中运行 NGINX（相当于 NGINX Ingress Controller）会大大降低服务请求等网络限制型操作（以 RPS 衡量）的性能。这是由于用于连接其他服务的底层容器网络堆栈所致。
另一方面，我们发现，对于 SSL/TLS 握手等 CPU 密集型操作（以 TPS 衡量），NGINX 在传统环境和 Kubernetes 环境中的性能无甚差异（实际上，Kubernetes 中的 TPS 略胜一筹）。
此外，当我们启用超线程 (HT) 时，TPS 大约增加了 10%。
| 内核数 | RPS | SSL TPS (RSA) | SSL TPS RSA (采用超线程) | 硬件成本 |
|---|---|---|---|---|
| 1 | 24,000 | 900 | 1,000 | $750 |
| 2 | 48,000 | 1,750 | 1,950 | $750 |
| 4 | 95,000 | 3,500 | 3,870 | $1,300 |
| 8 | 190,000 | 7,000 | 7,800 | $2,200 |
结语
以下关键要点可帮助您了解工作负载的最佳运行环境，以及所选环境的性能影响。
- 如果您的应用基础架构正执行网络密集型操作（在我们的测试中以 RPS 衡量），则在传统裸机环境中运行 NGINX 可实现最佳性能。由于 Kubernetes 环境中使用的底层容器网络堆栈，因此在 Kubernetes 中运行 NGINX Ingress Controller 会导致这种网络密集型操作的性能大幅下降。
- 虚拟管理程序会使网络密集型和CPU密集型操作的性能稍有下降，但仍是可以明显看到的（RPS 约为裸机值的 80%）。
- 如果您的应用基础架构正执行 CPU 密集型操作（在我们的测试中以 TPS 衡量），则 NGINX 在传统环境和 Kubernetes 环境中的性能几乎无甚差异。
- 在我们的测试中，对于加密等可并行化的 CPU 密集型操作，超线程将性能提高了大约 10%。
希望复制我们的测试过程或者在您的环境中试用 NGINX 和 NGINX Ingress Controller 吗？
下载 NGINX 开源版
下载基于 NGINX 开源版的 NGINX Ingress Controller
申请 NGINX Plus 30 天免费试用版
申请基于 NGINX Plus 的 NGINX Ingress Controller 30 天免费试用版
