乐趣区

关于nginx:NGINX-和-HAProxy基于公有云标准环境的用户体验测试对比

jiezi

原文作者：Amir Rawdat of F5
原文链接：NGINX 和 HAProxy：基于私有云规范环境的用户体验测试比照
转载起源：NGINX 官方网站

业内许多性能基准测试，都是基于峰值吞吐量或每秒申请数 (RPS)，但这些指标可能会过分简化理论站点的性能状况。以峰值吞吐量或靠近峰值吞吐量运行其服务的企业寥寥无几，因为无论采纳哪种形式，10% 的性能变动都会产生重大影响。站点所需的吞吐量或 RPS 不是有限的，而是取决于内部因素，例如站点必须服务的并发用户数量和每个用户的沉闷水平。最终重要的是您的用户可能获得最佳服务。最终用户并不在乎有多少人正在拜访您的站点。他们只在意本人所取得的服务，而且他们无奈承受因零碎过载而导致的性能低下。

因而，对于企业真正重要的是，即便在高负载下也要能为所有用户提供继续的低提早的可靠性能。在比照作为反向代理运行于 Amazon Elastic Compute Cloud (EC2) 之上的 NGINX 和 HAProxy 时，咱们从以下两方面着手探讨：

  1. 测量这两种代理能够牢靠解决的负载程度
  2. 计算提早指标百分位数的散布状况，这是与用户体验最间接相干的指标

测试程序和收集的指标

咱们应用压测工具 wrk2 模仿了一个客户端，在规定的时间段内收回间断的 HTTPS 申请。被测系统（HAProxy 或 NGINX）充当反向代理，与 wrk 线程模仿的客户端建设加密连贯，将申请转发到运行 NGINX Plus R22 的后端 Web 服务器，Web 服务器将生成的响应（一个文件）返回给客户端。

这三个组件（客户端、反向代理和 Web 服务器）都在 Ubuntu 20.04.1 LTS，EC2 的 c5n.2xlarge Amazon Machine Image (AMI) 实例上运行。

如上所述，咱们从每次测试运行中收集了残缺的提早指标百分位散布。提早指标是指客户端从生成申请到接管响应所用的工夫。提早百分位散布会将测试期间收集的提早测量值从高到低（即从延迟时间最长到最短）进行排序。

测试方法

客户端

借助 wrk2（版本 4.0.0），咱们在 Amazon EC2 实例上运行以下脚本：

taskset -c 0-3 wrk -t 4 -c 100 -d 30s -R requests_per_second --latency https://adc.domain.com:443/

为了模仿多个客户端拜访 Web 利用，咱们生成了 4 个 wrk 线程，这些线程共与反向代理建设 100 个连贯。在 30 秒的测试运行期间，该脚本生成了指定数量的 RPS。这些参数对应于以下 wrk2 选项：

  • ‑t选项 – 要创立的线程数 (4)
  • ‑c选项 – 要创立的 TCP 连接数 (100)
  • ‑d选项 – 测试期间的秒数（30 秒）
  • ‑R选项 – 客户端收回的 RPS 数量
  • ‑‑latency选项 – 输入后果蕴含校对的提早百分位信息

咱们在一组测试中逐步减少了 RPS 的数量，直到其中一个代理的 CPU 利用率达到 100%。更多信息请参阅下文“性能测试后果”一节。

客户端和代理之间的所有连贯均通过采纳 TLSv1.3 的 HTTPS 建设。咱们应用 256 位 ECC 密钥加密、PFS (Perfect Forward Secrecy，齐全向前窃密) 和 TLS_AES_256_GCM_SHA384 明码套件。（鉴于 TLSv1.2 仍被宽泛应用，因而咱们应用 TLSv1.2 从新运行了测试；后果与 TLSv1.3 十分类似，所以此处不再赘述。）

HAProxy：配置和版本控制

咱们用 HAProxy 2.3 版（稳定版）进行反向代理性能测试。

热门网站的并发用户数量微小。为了解决大规模流量，反向代理须要具备扩大能力以最大化利用多内核能力。现有两种根本的扩大形式：多过程和多线程。尽管 NGINX 和 HAProxy 都反对多过程，但二者之间有一个重要差异：在 HAProxy 的实现中，过程不共享内存（在 NGINX 中则得以共享）。HAProxy 无奈跨过程共享状态将产生以下几个问题：

  • 必须为每个过程独自定义配置参数（包含限度、统计数据和速率）。
  • 性能指标将按过程收集；整合这些指标须要额定的配置，而相干配置可能会非常复杂。
  • 每个过程独自解决健康状况查看，因而指标服务器会被按过程（而非料想中的按服务器）进行探测。
  • 会话长久化无奈实现。
  • 通过 HAProxy Runtime API 做出的动静配置更改只能利用于单个过程，因而必须为每个过程反复调用该 API。

因为上述问题，HAProxy 官网也强烈建议不要应用其多过程实现。上面引述摘自 HAProxy 配置手册：

应用多过程很难进行调试，强烈建议不要应用。

HAProxy 在 1.8 版中引入了多线程作为多过程的代替计划。多线程次要解决了状态共享问题，但正如咱们在下文“性能测试后果”一节中所述，在多线程模式下的 HAProxy 的性能又不如多过程的模式下的性能。

咱们的 HAProxy 配置蕴含了多线程模式 (HAProxy MT) 和多过程模式 (HAProxy MP) 的配置。为了在测试过程中在每个 RPS 级别上交替应用两种模式，针对相应的代码行，咱们通过适当批改正文，以及重启 HAProxy 以使不同的配置失效：

$ sudo service haproxy restart

以下是提供 HAProxy MT 的配置：在一个过程下创立了四个线程，并且每个线程绑定一个 CPU 核。HAProxy MP（上面正文的局部）中有四个过程，并且每个过程都固定在绑定到到一个 CPU 核上。

对于此段代码您能够点击文章《NGINX 和 HAProxy：基于私有云规范环境的用户体验测试比照》查看。

NGINX：配置和版本控制

咱们用 NGINX 开源版 1.18.0 作为反向代理性能测试。

为了应用设施上所有可用的内核（本例中为四个），咱们在 worker_processes 指令中增加了 auto 参数，这也是从咱们的存储库散发的 nginx.conf 文件中的默认设置。此外，还增加了 worker_cpu_affinity 指令，以便将每个 worker 过程绑定到一个 CPU（第二个参数中的每个 1 示意设施中的一个 CPU）。

对于此段代码您能够点击文章《NGINX 和 HAProxy：基于私有云规范环境的用户体验测试比照》查看。

性能测试后果

因为反向代理充当利用的前端，因而其性能至关重要。

咱们逐步减少 RPS 的量级来测试每个反向代理（NGINX、HAProxy MP 和 HAProxy MT），直到其中一个的 CPU 利用率达到 100%。在 CPU 未耗尽的 RPS 能力上，这三个反向代理的性能并驾齐驱。

HAProxy MT 的 CPU 利用率首先达到 100%（RPS 为 85,000），在达到该值后，HAProxy MT 和 HAProxy MP 的性能都急剧下降。下图展现了在该负载级别上每个反向代理的提早百分位散布。该图应用 GitHub 上提供的 HdrHistogram 程序依据 wrk 脚本的输入后果绘制而成。

RPS 85,000 级别上，在第 90 个百分位数上，HAProxy MT 的提早指标骤升直，在逐步晋升到大概 1100 毫秒 (ms) 时逐步趋于平稳。

较之 HAProxy MT，HAProxy MP 的性能更好 —— 其提早在第 99 个百分位前始终以较慢的速度回升，之后在达到大概 400 毫秒时开始趋于平稳。（以上察看后果证实了 HAProxy MP 更为高效：HAProxy MT 在每个 RPS 级别上应用的 CPU 略多于 HAProxy MP。）

NGINX 在任何百分位上简直都没有提早。简直所有用户拜访可能呈现的最高提早（在第 99.9999 个百分位）大概为 8 毫秒。

对于用户体验，这些后果阐明了什么呢？正如引言所述，从最终用户的角度来看，真正重要的指标是响应工夫，而非被测系统的服务工夫。

人们普遍存在一种误会，认为提早散布中的中位数最能代表用户体验。事实上，中位数是大概一半的响应都要体验到的更高的延时！用户通常会在每次页面加载时收回许多申请并拜访许多资源，因而他们的一些申请必然会在图表的上百分位（第 99 到第 99.9999 个百分位）处呈现提早。用户无法忍受性能低下，而高百分位的延时指标恰好代表了少数申请都会经验的延时，因而更容易被他们留神到。

举个例子：您在杂货店结账的体验取决于从您排队结账的那一刻到来到商店所用的工夫，而不仅仅是收银员进行商品扫码结算所破费的工夫。例如，如果您后面的一位顾客对某件商品的价格提出质疑，而收银员必须找人进行核实，那么您的整体结账工夫就会比平时长得多。

为了将这一点计入提早后果，咱们须要纠正所谓的_coordinated omission_，其中（如 wrk2README 文件开端的正文中所述）“高提早响应会触发负载生成器与服务器进行协调，从而防止在高提早期间进行测量”。侥幸的是，wrk2 默认纠正了 coordinated omission（无关 coordinated omission 的更多详细信息，请参阅 README 文件）。

当在 85,000 RPS 下 Haproxy MT 耗尽 CPU 时，许多申请都会呈现高提早。这些状况理当纳入数据，因为咱们正在调整 coordinated omission。只有一两个高提早申请便会提早页面加载，让人感觉性能欠佳。假如一个实在零碎一次为多位用户提供服务，即便只有 1% 的申请呈现高提早（第 99 个百分位的值），大部分用户都可能会受到影响。

结语

性能基准测试的要点之一是确定利用是否具备足够的响应能力来满足用户需要并留住用户。

NGINX 和 HAProxy 均基于纯软且采纳事件驱动型架构。只管 HAProxy MP 的性能优于 HAProxy MT，但因为无奈在各个过程之间共享状态，因而治理变得更加简单，详见上文 HAProxy：配置和版本控制一节。HAProxy MT 打消了这些局限性，但却升高了性能，如上述后果所示。

借助 NGINX，您则无需做出取舍 —— 因为过程之间共享状态，所以无需采纳多线程模式。您能够取得多过程的卓越性能，而不会遇到 HAProxy 中的限度 —— 毕竟，这种限度是如此重大，以至于 HAProxy 间接倡议不要应用其多过程实现。

如欲应用 NGINX 开源版，请下载二进制文件或源代码。

更多资源

NGINX 惟一中文官网社区，尽在 nginx.org.cn

更多 NGINX 相干的技术干货、互动问答、系列课程、流动资源：

开源社区官网：https://www.nginx.org.cn/
微信公众号：https://mp.weixin.qq.com/s/XVE5yvDbmJtpV2alsIFwJg

退出移动版