如何运行基准测试

进行基准测试可能有许多原因

• 规模和容量规划
• 产品评估（RabbitMQ 能否处理我的负载？）
• 发现适合您的工作负载的最佳配置

在这篇文章中，我们将介绍运行 RabbitMQ 基准测试的各种选项。但在我们开始之前，你需要一种查看结果和系统指标的方法。

RabbitMQ 可观测性

您已通过 RabbitMQ 集群每秒路由 X 条消息，并得出结论认为您已达到峰值吞吐量，但您是否考虑过

• 您的 CPU 在那时已达到最大值，无法应对任何高于该负载的峰值
• 您接近网络带宽、磁盘 IOPS 等，并且无法应对任何超出该负载的峰值
• 您的端到端延迟以分钟为单位，而不是毫秒
• 您丢失了数千条消息，因为在对代理和网络施加巨大压力时，您没有使用确认或确认。

您必须能够看到不仅仅是吞吐量数字。 

从 3.8.0 开始，我们提供了 rabbitmq_prometheus 插件。 了解如何 使 Grafana、Prometheus 和 RabbitMQ 协同工作，并深入了解您的 RabbitMQ 实例。

查看我们 发布的 Grafana 仪表板，不仅可以深入了解队列计数、连接计数、消息速率等，还可以从 Erlang 的角度深入了解幕后发生的情况。您还可以安装无数的系统指标仪表板和代理来查看系统指标，例如 CPU、RAM、网络和磁盘 IO。例如，查看 node_exporter，它可以深入了解硬件和操作系统的行为。

使用 Prometheus 等解决方案的另一个原因是，当您将 RabbitMQ 推至极限时，管理 UI 可能会变得缓慢或无响应。UI 试图在一个可能已经接近 100% CPU 利用率的机器上运行。

一些基准测试的注意事项

做

• 使用我们的可观测性工具！
• 尝试使您的基准测试工作负载尽可能地与您的实际工作负载匹配，否则您就是在比较苹果和橘子。
• 花时间了解可能影响性能的概念：发布者确认、消费者确认、消息大小、队列计数（见下一标题）。
• 确保托管负载生成器的虚拟机不是瓶颈。要么过度配置您的负载生成机器，要么监控它（CPU 和网络）。
• 注意具有突发资源（如 CPU、网络和磁盘）的 IaaS。如果您只查看测试的前 30 分钟，您可能会认为您选择的磁盘能够胜任。如果您让基准测试继续运行，您可能会看到吞吐量一旦您的突发资源用完就会下降。
• 请注意，如果您在可能具有复杂网络设置（例如双 NAT、VPC 网关、负载均衡器、防火墙等）的共享本地环境中运行基准测试，那么您不一定是在对 RabbitMQ 进行基准测试，而是在对您的 IT 基础设施进行基准测试。 

如果您在隔离环境和主要 IT 基础设施中都运行基准测试，它可以帮助您隔离和优化生产/测试环境中次优的区域。

不要

• 在不限制发布者速率的情况下运行端到端延迟测试。只有当负载在代理容量范围内时，延迟测试才有用。
• 在与 RabbitMQ 代理相同的机器上运行负载生成器（如 perf-test）。
• 在共享本地环境中运行基准测试，事先不告诉您的 IT 运维人员。在您的基准测试中占用所有网络带宽往往会让您的 IT 运维人员感到紧张。
• 在云 IaaS 中运行基准测试，然后使用这些结果来确定本地环境的规模。根据 CPU 代、存储配置、网络拓扑等，性能可能存在巨大差异。即使在不同的云之间也存在差异！

一些常见的性能影响因素

以下是您在改变基准测试的不同方面时可以预期的某些情况。

• 一个队列具有吞吐量限制，因此创建几个队列可以提高总吞吐量。但是，创建数百个队列随后会降低总吞吐量。每个 CPU 线程一个或两个队列往往可以提供最高的吞吐量。超过此数量，上下文切换会降低效率。
• 使用发布者确认和消费者确认的吞吐量低于不使用它们的情况。但在使用数百个发布者和队列时，发布者确认实际上可以提高性能，因为它们充当发布者的有效背压机制——避免吞吐量出现大幅波动（详细了解 流量控制）。
• 发送一条消息，等待发布者确认，然后发送下一条消息，依此类推，速度非常非常慢。使用批量或管道策略以及发布者确认可以显着提高吞吐量（/tutorials/tutorial-seven-java.html 或 /tutorials/tutorial-seven-dotnet.html）
• 不使用消费者预取会提高吞吐量（但不建议这样做，因为它可能会压垮消费者——预取是我们如何对 RabbitMQ施加背压的方式）。预取值为 1 会显着降低吞吐量。尝试使用预取来找到适合您工作负载的正确值。
• 发送小消息将提高吞吐量（尽管 MB/s 会很低），而发送大消息将降低吞吐量（但 MB/s 会很高）。
• 拥有少量发布者和消费者将带来最高的吞吐量。创建数千个将导致总吞吐量降低。
• 经典队列比复制队列（镜像/仲裁）快。复制因子越大，队列越慢。

一个常见模式是，一旦您超过几十个队列和/或客户端，总吞吐量就会下降。连接和连接越多，上下文切换就越多，效率就越低。CPU 内核数量是有限的。 如果您有数千个队列和客户端，这不是一件坏事，但请意识到与您拥有几十个或数百个客户端/队列相比，您可能无法获得相同的总吞吐量。

选项 #1 - 使用您现有的应用程序

如果您需要进行基准测试以进行容量规划或查找最佳配置，那么使用您现有的应用程序最有可能产生最有用的结果。

合成基准测试的问题在于，它们会告诉您您的 RabbitMQ 安装将如何应对所选负载生成器生成的负载，这可能与您的实际使用情况大不相同。

使用您的实际应用程序的问题在于，生成负载可能需要一些设置工作。 

其次，除非您已经对其进行了检测，否则您将无法获得端到端延迟指标。当然，您可以添加它。您可以在消息头中添加时间戳，并在消费者中提取该头并发布指标。大多数语言都具有高效地发出指标的库，无需手动编写任何内容（例如 https://micrometer.io/）。还要考虑到，如果没有像 NTP 这样的时钟同步，端到端延迟指标将不准确，即使有，也可能存在抖动。

选项 #2 - Perf Test

PerfTest 是我们推荐用于对 RabbitMQ 进行简单工作负载的合成基准测试的工具。 PerfTest 位于 GitHub 上，并提供了一些不错的 说明。要自己运行它，请按照 安装说明 进行操作。 

它甚至有自己的 Grafana 仪表板！ 

选项 #3 - Perf Test + CloudFoundry

请参阅我们在 GitHub 上的 工作负载 项目。它将向您展示如何在 CloudFoundry 上部署和测试各种工作负载。

选项 #4 - RabbitTestTool

这是一个我个人使用（并构建）的 实验性工具，用于进行 自动探索性测试。它是一个功能强大但复杂的工具，因此可能不是您的理想选择。它更像是一个 QA 工具，而不是供客户对其自己的设置进行基准测试。

但它有一些可能让您感兴趣的功能。

首先，它具有 模型驱动、基于属性的测试模式，可以检测数据丢失、排序违规（无重新传递标志）、重复传递（无重新传递标志）和可用性。您可能对数据丢失和可用性检测感兴趣。重复项和排序仅在我们可能在新的功能中存在错误的 alpha 和预 alpha 版本中才有用。

您可以使用此工具练习蓝/绿部署或滚动升级，以确保您可以在不丢失数据和可用性的情况下执行操作。

它还具有高度可自定义的 EC2 部署和基准测试编排。可以在不同的 AWS 硬件、RabbitMQ 版本和配置上设置许多并排基准测试。但是，同样，这非常可配置，因此也很复杂。

选项 #5 - RabbitMQ 基准测试 X 项目

好的，所以名称仍在开发中，但它代表了一个新项目，我们的目标是让我们的团队以及更广泛的社区从中受益，它将成为统治所有基准测试项目的唯一项目。

计划是使用像 PerfTest 这样的基准测试工具，并结合 Kubernetes API 来整合编排（代理、磁盘等）和基准测试工具本身。编排（RabbitMQ 的部署、负载生成、可观察性）通常是基准测试中最繁琐的部分，因此我们希望这个项目能够一劳永逸地解决这个问题——不仅对我们，而且对所有人。

总结

基准测试可能难以做好，但如果正确执行，它可以提供有价值的信息。关键是尽可能多地使用可观察性工具，并尽可能地模拟您的实际工作负载。充分理解发布者确认和消费者确认的使用至关重要，它们在流量控制中的作用以及它们对性能的影响。

在后续关于性能的博文中，我将包含您需要重现负载生成方面的 PerfTest 参数。