使用自动化破解MQTT性能：基准测试的实施

HiveMQ为解决诸多性能挑战（从不可靠的公共基准测试到云部署中的噪音邻居）提出了一个解决方案，这个过程历时数月，最终诞生了自动化系统基准测试。

系统基准测试是一组围绕自动化基准测试和基准案例的工具，代表了客户的工作负载。工程师在开发和质量保证期间都会使用系统基准测试。在开发阶段，系统基准测试被用作设计辅助工具，帮助工程师快速迭代众多解决方案，并选择最佳方案。而在质量保证阶段，目的是不同的。在这个阶段，系统基准测试帮助发现生产代码中的性能回归问题，确保系统在发布给客户之前不会表现得更差。

自动化系统基准测试可以在各种云环境中执行，这要归功于Terraform。在本部分中，我们将重点放在被HiveMQ客户广泛使用的AWS平台上。

自动化系统基准测试概述

系统基准测试跨越了两个组织域——AWS（云提供商）和HiveMQ。

HiveMQ域包含系统基准测试代码库和运行Jenkins的自动化服务器。代码库包含管理、汇总和验证性能测试结果的自动化脚本（主要用Python编写）以及基准测试案例。每个基准案例包括三个组件：要评估的指标列表、Terraform配置（特别是虚拟机类型及其数量以及MQTT Broker配置）和HiveMQ Swarm场景。HiveMQ Swarm场景指定了在负载生成期间将执行的测试阶段。想了解更多关于HiveMQ Swarm的信息，请查看其产品页面。简而言之，这个负载测试工具读取脚本文件，创建并管理客户端，驱动它们通过多个阶段，如连接、订阅、发布、取消订阅和断开连接，并进行偶尔的条件检查。

AWS域包含测试部署和历史数据的持久存储。测试部署只在实验运行期间存在，一旦实验结束，测试部署将完全拆除以避免资源浪费。测试部署包括负载测试工具（HiveMQ Swarm）的部署、被测试的MQTT Broker（HiveMQ Broker）的部署以及监控基础设施（InfluxDB和Grafana）。负载测试工具和MQTT Broker都运行在多个虚拟机上，而监控则只需一台虚拟机。即使每次运行后测试部署被拆除，自动化工具会提取结果，处理并验证，然后将结果添加到AWS Athena中的测试结果历史记录中。

下图显示了组织域的概述。灰色区域表示组织域。大白框分别组连接代码库和测试部署的元素。绿色框表示永久存在的实体，而黄色框表示临时实体。

触发系统基准测试

有多种方式触发系统基准测试。在HiveMQ，我们谨慎地进行此操作。如果更改不涉及任何性能关键组件，则无需运行完整的性能测试。但是，如果有必要，可以手动触发相应的Jenkins任务，只需将Jenkins指向正确的分支，指定所需的迭代次数和场景细节（如有需要），然后点击“构建”按钮即可。

Jenkins用于自动化系统基准测试

系统基准测试运行的报告将包含所有相关指标及其一些数值。如果某个指标未通过验证，则会标记为红色。如果其性能超过预期，则会标记为绿色，否则，像下面的示例截图中的所有指标一样，都是普通的黑色。

系统基准测试报告

即使工程师不触发系统基准测试，它们仍会在主分支上每周运行两次的计划任务中运行。这种安全网可以在发布前及早发现可能的性能回归问题。

系统基准测试：收集和汇总

为了确保收集的性能结果代表系统行为，Jenkins每个基准案例都会运行多次。具体次数由工程师决定，但默认次数为三次。遵循最高的质量保证标准，每个基准案例执行前都会创建并销毁独立的测试部署。

在销毁测试部署之前，运行自动化脚本的Jenkins会将基准案例中指定的相关指标收集到简单的CSV文件中。一旦基准案例的所有执行完成，结果将汇总到所有迭代中。我们对结果应用各种汇总，从计算普通平均值到百分位数和标准差。一旦整个系统基准测试运行完成，文件将被推送到AWS Athena中进行“永久存储”。在那里，工程师可以提取汇总的性能结果并使用Athena的查询功能进行分析（请参见下面的截图）。

使用Athena的查询功能提取汇总的性能结果并进行分析

案例完成：MQTT Broker的全面基准测试

我提到过，HiveMQ的系统基准测试包含多个基准案例。每个基准案例专注于系统行为的某个特定方面，无论是特定的MQTT服务质量级别、某些虚拟机实例的大小，还是某种负载模式。有时，这些方面是结合在一起的。

这些基准案例共同构成了我所谓的全面基准测试。这个造词描述了一种在评估MQTT Broker性能方面达到全面性的能力。这是系统基准测试的一个重要特征，因为MQTT协议不仅提供了各种调优选项，如QoS级别、订阅类型和到期时间，而且在将其用例引入HiveMQ MQTT平台的各个行业中，设置和负载模式及其量级差异巨大。

让我们深入探讨涵盖HiveMQ平台在生产中面临的80%场景的核心基准案例。合成这些基准测试时涉及以下测试维度：

• 实例类型（多核心与常规核心数量）；
• 实例数量（小型部署或大型部署）；
• 消息分发模式（一个发布者到一个订阅者，多个发布者到一个订阅者，和一个发布者到多个订阅者）；
• 订阅类型（独占或共享）；
• 消息负载大小（小或大）；
• 服务质量级别（QoS0，QoS1和QoS2）；
• 负载模式（突发的发布高峰或稳定的）；
• 主要评估特性（延迟测试或吞吐量测试）。

空闲连接案例

此案例评估单个HiveMQ节点在六分钟内建立一百万个连接的能力。虽然不会将Broker最大化，但此测试作为安全网，以防止HiveMQ Broker节点常规处理的连接数量回归问题。

发布（PUBLISH）汇聚案例

此案例评估四节点HiveMQ集群在每秒30,000个发布包总输入速率下，将30,000个发布客户端的发布包汇聚到仅十个订阅中的能力。此案例提供了对HiveMQ Broker出站消息分发子系统性能的洞察。

发布（PUBLISH）扩散案例

这是汇聚的相反操作。它也在相同的AWS部署配置上运行，使用四个节点。这次，每个由200个发布者组生成的发布包通过Broker分发到250个订阅者的队列中。此案例是深入了解HiveMQ Broker入站消息分发子系统性能的宝贵工具。

发布（PUBLISH）突发案例

一些客户（主要在联网汽车领域）面临着负载的急剧增加和减少。此基准案例尝试通过短期测试来捕捉这种情况。两万个发布者在五个短批次中将其负载推送到两万个订阅者，每分钟10,000个MQTT包。此案例使工程团队能够评估Broker如何缓解负载急剧变化的影响并从压力中恢复。

稳定的大发布（PUBLISH）供应案例

在JSON和MQTT Sparkplug的世界中，5、10和100 KiB的发布负载并不罕见。多次写入大负载到磁盘可能会因稳定存储（计算机资源中最慢的一种）的硬件限制而影响性能。为了提供高持