RabbitMQ 3.10 性能改进

RabbitMQ 3.10 于 2022 年 5 月 3 日发布，其中包含许多新功能和改进。这篇博文概述了该版本中的性能改进。简而言之，您可以期待更高的吞吐量、更低的延迟和更快的节点启动速度，尤其是在启动时导入大型定义文件时。

概述

首先，请查看3.10 版本概述博文，以了解该版本新增内容的高级概述。在这里，我们只关注性能改进和对性能有影响的功能。此处介绍的一些改进已回传到 3.9.x，因此为了演示差异，我们将使用 3.9.0 作为参考点。

如果您暂时无法升级到 3.10，请确保您至少运行最新的 3.9.x 修补程序版本以利用这些优化。

RabbitMQ 3.9 与 3.10

让我们在几种不同的场景中比较 RabbitMQ 3.9 和 3.10。请记住，这些是特定的基准测试，可能不一定反映您的工作负载的性质和性能。

您可以使用 RabbitMQ 负载测试工具自行运行这些测试或类似的测试，例如perf-test 和stream-perf-test。

环境

这些测试使用以下环境执行

• 具有 e2-standard-16 节点的 GKE 集群
• 使用我们的 Kubernetes 运算符部署的 RabbitMQ 集群，具有以下资源和配置

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: ...
spec:
  replicas: 1 # or 3
  image: rabbitmq:3.10.1-management # or rabbitmq:3.9.0-management
  resources:
    requests:
      cpu: 8
      memory: 16Gi
    limits:
      cpu: 8
      memory: 16Gi
  persistence:
    storageClassName: premium-rwo
    storage: "3000Gi"
  rabbitmq:
    advancedConfig: |
      [
      {rabbit, [
          {credit_flow_default_credit,{0,0}}
      ]}
      ].

关于环境的一些说明

1. 对于许多测试（甚至生产工作负载），这些资源设置过高。但是，这是我们团队在 RabbitMQ 负载测试中的标准配置。
2. 使用更好的硬件（包括 Google Cloud）您应该能够获得更高的值
3. 信用流已禁用，因为否则单个快速发布者将被限制（以防止过载并为其他发布者提供公平的机会），这在生产环境中是正确的做法，但在服务器负载测试中没有意义。

场景 1：一个队列、快速发布者和消费者

在第一个场景中，我们将只使用 1 个队列，并使用 2 个发布者和 2 个消费者。我们将测试消息大小为 10、100、1000 和 5000 字节。

我们使用 2 个发布者，因为单个发布者无法在某些配置中充分利用队列，尤其是在消息非常小的情况下。请注意，RabbitMQ 3.11（目前在 master 中）已经有一些路由效率改进，因此对于将来的版本可能并非如此。

此工作负载中使用了以下perf-test 标志

# classic queues (with an exactly=3 mirroring policy where applicable)
perf-test --producers 2 --consumers 2 --confirm 3000 --multi-ack-every 3000 --qos 3000 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --auto-delete false --flag persistent --queue cq

# quorum queues
perf-test --producers 2 --consumers 2 --confirm 3000 --multi-ack-every 3000 --qos 3000 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --quorum-queue --queue qq

场景 1：1 个队列、2 个发布者和 2 个消费者；消息大小为 10、100、1000 和 5000 字节（每个 15 分钟）

观察结果

• 仲裁队列的吞吐量是经典镜像队列 (CMQ) 的几倍
• 在某些场景中，3.10 中的仲裁队列可以实现更高的吞吐量，甚至高达 50%
• 在某些场景中，经典队列 v2 已经比 v1 略好
• CMQ 没有获得任何新的改进，并且将在 RabbitMQ 4.0 中删除；请根据需要迁移到仲裁队列、流或非镜像经典队列

场景 2：一个队列、10000 条消息/秒

在前面的场景中，RabbitMQ 中的一些代码路径始终以最大速度或接近最大速度运行。这一次，我们将设置 10000 条消息/秒的固定目标吞吐量，并随着消息大小随时间推移而增加，比较不同的环境是否能够维持此工作负载。

由于预期吞吐量已知，我们将重点关注测量延迟及其可变性。

在此场景中使用了以下 perf-test 标志

# classic queues (with an exactly=3 mirroring policy where applicable)
perf-test --rate 10000 --confirm 3000 --multi-ack-every 3000 --qos 3000 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --auto-delete false --flag persistent --queue cq

# quorum queues
perf-test --rate 10000 --confirm 3000 --multi-ack-every 3000 --qos 3000 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --quorum-queue --queue qq

仲裁队列再次自信地击败了经典镜像队列 (CMQ)

场景 2：1 个队列、1 个发布者和 1 个消费者；消息大小为 10、100、1000 和 5000 字节（每个 15 分钟）

让我们放大非镜像经典队列，以比较 v1 和 v2 消息存储和队列索引实现。我们可以看到 CQv2 提供了更低且更一致的延迟

场景 2：1 个队列、1 个发布者和 1 个消费者；消息大小为 10、100、1000 和 5000 字节（每个 15 分钟）

在此测试中，单节点仲裁队列 3.9 和 3.10 的性能非常相似（请参阅第一个图表的图例）。让我们关注 3 节点集群

场景 2：1 个队列、1 个发布者和 1 个消费者；消息大小为 10、100、1000 和 5000 字节（每个 15 分钟）

如您所见，3.10 版本中的仲裁队列提供了明显更低且更一致的延迟。由于某些仲裁队列操作的批处理或周期性性质，仍然存在峰值。这是未来版本改进的领域。

场景 3：500 个队列、总计 5000 条消息/秒

在此场景中，我们将有 500 个队列，每个队列都有 1 个发布者每秒发布 10 条消息，以及一个消费这些消息的消费者。因此，总预期吞吐量为每秒 5000 条消息。我们再次运行此场景一个小时，每 15 分钟更改一次消息大小（10、100、1000 和 5000 字节）。

# classic queues (with an exactly=3 mirroring policy where applicable)
perf-test --producers 500 --consumers 500 --publishing-interval 0.1 --confirm 10 --multi-ack-every 100 --qos 100 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --queue-pattern cq-%d --queue-pattern-from 1 --queue-pattern-to 500 \
          --auto-delete false --flag persistent

# quorum queues
perf-test --producers 500 --consumers 500 --publishing-interval 0.1 --confirm 10 --multi-ack-every 100 --qos 100 \
          --variable-size 10:900 --variable-size 100:900 --variable-size 1000:900 --variable-size 5000:900 \
          --quorum-queue --queue-pattern qq-%d --queue-pattern-from 1 --queue-pattern-to 500

场景 3：500 个队列、1 个发布者、1 个消费者、每个队列 10 条消息；消息大小为 10、100、1000 和 5000 字节（每个 15 分钟）

观察结果

1. 只有 CMQ 难以维持预期的 5000 条消息/秒的吞吐量
2. 在整个测试过程中，经典队列 v2 的延迟最低且最一致
3. 3.9.0 CMQ 环境的发布延迟非常高；我没有调查原因，只需使用仲裁队列或流！

由于经典队列（尤其是镜像的 3.9.0 环境）在图表中占据了很大一部分，因此这里有相同的图表，但重点关注经典队列 v2 和 3.10 仲裁队列

场景 3：仅 3.10 环境

如上所述，仲裁队列的延迟并不像我们希望的那样一致，但大多数情况下，它们保持在 25 毫秒以内。这仍然是在 500 个队列、总计 5000 条消息/秒的情况下，使用 10/100/1000 字节的消息，并且使用 5000 字节的消息时也不会高出太多。

对于 3 节点仲裁队列，这是一个退化的（极端情况）集群，所有队列领导者和所有连接都在单个节点上。这样做是为了使测试结果在运行之间以及单节点和 3 节点集群之间更具可比性。

场景 4：长仲裁队列

在 3.10 之前，当仲裁队列很长时，其性能表现不佳——为消费者检索最旧的消息是一项代价高昂的操作。在此场景中，我们首先将使用 2 个发布者发布 1000 万条消息，然后将使用两个消费者消费所有消息。

# publish 10 milion messages
perf-test --producers 2 --consumers 0 --confirm 3000 --pmessages 5000000 \
          --queue-args x-max-in-memory-length=0 --quorum-queue --queue qq

# consume 10 milion messages
perf-test --producers 0 --consumers 2 --multi-ack-every 3000 --qos 3000 --exit-when empty \
          --queue-args x-max-in-memory-length=0 --quorum-queue --queue qq

请注意，从 3.10 开始，仲裁队列会忽略 x-max-in-memory-length 属性。它仍然可以通过策略进行配置，但不会有任何效果——队列的行为就像它设置为 0 一样。

场景 4：发布 1000 万条消息，然后消费

观察结果

1. 在 3.10.1 中，发布和消费消息花费的时间大致相同（每个大约 3 分钟）
2. 3.9.0 需要花费两倍的时间来发布消息（大约 6 分钟）
3. 单个节点 3.9.1 需要近 15 分钟才能清空队列，而 3 节点集群则需要额外 2 分钟
4. 3.9 实例都以大约 10000 条消息/秒的速度开始消费，并随着时间的推移逐渐提高。当队列较短时，3 节点 3.9.0 集群的消费速度显着提高

值得注意的是 3.9 发布者图表中的两个下降点（橙色线）。集群遇到了内存警报，因此发布者暂时被阻止。尽管 3.10 在那时执行了更多工作（更快地发布和消费），但这并没有发生在 3.10 环境中。

3.10 测试中的仲裁队列平均使用的内存比经典队列多，因为它们会将有关消息的元数据保存在内存中，但它们使用的内存比 3.9 中使用的少。

以下是执行大部分工作的两个节点（承载所有队列领导者和所有连接）之间的直接比较

场景 4：发布 1000 万条消息，然后消费，内存使用情况

更快的导入和声明

对于那些在启动时导入定义的用户，节点在升级到 3.10 后应该花费更少的时间启动。有多个更改和功能导致了这一点，并且预期行为取决于您的定义以及您使用和将使用/配置的功能。以下是一个摘要

1. 如果您使用 load_definitions 配置选项，并且在 JSON 文件中有很多定义，则节点应该能够更快地启动，而无需您执行任何操作。对于拥有数千个队列的用户，这可以节省每个节点启动几分钟的时间。这里的主要区别在于，在 3.10 中，重新声明已存在的实体应该快得多。集群中的节点通常共享相同的配置文件，因此每个节点都会尝试相同的导入，但除了第一个节点之外，所有节点实际上都会重新导入现有实体。在节点重新启动时，假设您没有删除这些实体，所有节点都可以更快地启动。

2. 如果您设置了一个新属性 definitions.skip_if_unchanged = true，如果定义文件的校验和与先前导入时相同，则 RabbitMQ 将完全跳过导入。对于具有大型定义文件的集群，这可以节省每个节点几分钟的时间。这与前一点类似，除了您需要选择加入（设置属性）并且加速更高，因为不尝试导入显然比检查实体是否已存在更快。

其他改进

Erlang 25

此版本支持Erlang 25，它引入了一些编译器和运行时效率改进。这在 64 位 ARM CPU 上最为明显，因为 Erlang 25 中的 JIT 现在支持该架构。

启动时导入定义

在节点启动时导入定义的集群中，实际上集群中的每个节点都会导入相同的定义，因为所有节点都使用相同或几乎相同的配置文件。

这通常会导致两个问题之一，具体取决于事件的确切时间。

• 如果节点一个接一个地启动，所有队列通常最终都会位于单个节点上，因为在导入时集群中只有一个节点。
• 如果节点并行启动，则多个节点尝试声明相同定义时会出现大量争用。

在 RabbitMQ 3.10 中，一些重新导入优化通常有助于解决第二个问题。

此外，cluster_formation.target_cluster_size_hint 是一个新的设置，现在可以将其设置为告诉 RabbitMQ 集群完全形成后预计有多少个节点。

有了这些额外信息，只有最后一个加入集群的节点才会导入定义。主要好处是仲裁队列应该在节点之间得到很好的平衡（受领导者放置设置的影响）。过去，如果导入在第一个节点启动后立即发生，则其他节点将有效地空闲启动，因为所有队列在它们启动时已经在运行。

结论

RabbitMQ 3.10 中已经发布了许多改进，其中一些也已回传到最近发布的 3.9 修补程序中。

我们一直在寻找使事情变得更快的方法。但是，RabbitMQ 可以以多种不同的方式进行配置和使用，并且许多改进都是针对工作负载的。我们非常感谢您的帮助 - 如果您希望 RabbitMQ 在特定场景中更快，请与我们联系并告诉我们您的工作负载。理想情况下，如果您能够使用perf-test重现问题，我们将很乐意看看我们能做些什么来提高吞吐量、降低延迟或减少内存使用。