27 篇关于“性能”的博文

这篇博文概述了 AMQP 1.0 流量控制相较于 AMQP 0.9.1 的十大优势，并通过两个基准测试展示了显著的性能提升。此外，我们深入探讨了强大的 AMQP 1.0 流量控制原语及其在 RabbitMQ 中的应用。

这篇博文表明，RabbitMQ 4.0 中的原生 AMQP 1.0提供了比 RabbitMQ 3.13 中的 AMQP 1.0 显著的性能和可扩展性改进。

此外，这篇博文还表明，在 RabbitMQ 4.0 中，AMQP 1.0 的性能可能略优于 AMQP 0.9.1。

我们已经在单独的博文中宣布了 3.13 的两个主要新功能

• 支持 MQTT 协议版本 5
• 支持流筛选

本文重点介绍此版本中对经典队列的更改

• 经典队列存储格式版本 1 已弃用
• 经典队列消息存储的新实现

RabbitMQ 3.12 将很快发布，其中包含许多新功能和改进。这篇博文重点介绍了与性能相关的差异。最重要的更改是经典队列的lazy模式现在是标准行为（更多信息请参见下文）。新的实现应该更加节省内存，同时提供比早期版本中lazy或non-lazy实现更高的吞吐量和更低的延迟。

为了获得更好的性能，我们强烈建议切换到经典队列版本 2 (CQv2)。

RabbitMQ 的核心协议一直是 AMQP 0.9.1。为了支持 MQTT、STOMP 和 AMQP 1.0，代理通过其核心协议透明地进行代理。虽然这是一种通过支持更多消息传递协议来扩展 RabbitMQ 的简单方法，但它会降低可扩展性和性能。

在过去的 9 个月里，我们重写了MQTT 插件，使其不再通过 AMQP 0.9.1 进行代理。相反，MQTT 插件会解析 MQTT 消息并将其直接发送到队列。这就是我们所说的原生 MQTT。

结果令人惊叹

1. 内存使用量最多下降 95%，在许多连接情况下可节省数百 GB 的内存。
2. RabbitMQ 首次能够处理数百万个连接。
3. 端到端延迟下降 50% - 70%。
4. 吞吐量提高 30% - 40%。

原生 MQTT 将 RabbitMQ 变成一个 MQTT 代理，为更广泛的物联网用例打开了大门。

原生 MQTT 在 RabbitMQ 3.12 中提供。

最近的 Erlang/OTP 版本附带了Linux perf 支持。这篇博文提供了分步说明，说明如何在 RabbitMQ 中创建 CPU 和内存火焰图，以快速准确地检测性能瓶颈。我们还提供了火焰图如何帮助我们提高 RabbitMQ 消息吞吐量的示例。

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

TL;DR​

• Erlang 24 将于 5 月发布，它为 RabbitMQ 用户提供了显著的性能提升
• 同时支持 Erlang 24 和 22 无法实现，因此，2021 年 5 月初将停止支持 Erlang 22
• 如果您使用 Erlang 22，请立即升级到 23.2：它应该是即插即用的替换
• 使用RabbitMQ Kubernetes 运算符、Docker 社区镜像 和VMware Tanzu RabbitMQ for VMs 的现代版本的使用者不受影响，因为这些项目今天都使用 Erlang 23

在上一篇文章中，我们开始使用法定人数队列对我们的工作负载进行规模分析。我们专注于消费者能够跟上的理想情况，这意味着没有队列积压，并且集群中的所有代理都正常运行。通过运行一系列模拟不同强度工作负载的基准测试，我们确定了按每月每 1000 条消息/秒的成本计算的前 5 个集群大小和存储卷组合。

1. 集群：7 个节点，8 个 vCPU（c5.2xlarge），gp2 SDD。成本：54 美元
2. 集群：9 个节点，8 个 vCPU（c5.2xlarge），gp2 SDD。成本：69 美元
3. 集群：5 个节点，8 个 vCPU（c5.2xlarge），st1 HDD。成本：93 美元
4. 集群：5 个节点，16 个 vCPU（c5.4xlarge），gp2 SDD。成本：98 美元
5. 集群：7 个节点，16 个 vCPU（c5.4xlarge），gp2 SDD。成本：107 美元

需要运行更多测试以确保这些集群能够处理诸如代理故障和在中断或系统缓慢期间累积的大量积压等情况。

所有法定人数队列都声明了以下属性

• x-quorum-initial-group-size=3
• x-max-in-memory-length=0

x-max-in-memory-length 属性强制法定人数队列在安全的情况下立即从内存中删除消息正文。您可以将其设置为更长的限制，这是最激进的设置 - 旨在避免在消费者无法跟上的情况下内存大幅增长，代价是在消费者无法跟上的情况下进行更多磁盘读取。如果没有此属性，消息正文将始终保留在内存中，这会导致内存增长到内存警报触发的地步，从而严重影响发布率 - 在此工作负载案例研究中我们希望避免这种情况。

在本规模系列的第一篇文章中，我们介绍了工作负载、测试以及 AWS ec2 上的集群和存储卷配置。在本篇文章中，我们将使用法定人数队列运行规模分析。我们还对镜像队列进行了规模分析。

在本篇文章中，我们将运行强度递增测试，这些测试将在理想条件下测量不同发布率下候选集群的大小。在下一篇文章中，我们将运行弹性测试，以衡量我们的集群在不利条件下是否能够处理我们的目标峰值负载。

所有法定人数队列都声明了以下属性

• x-quorum-initial-group-size=3（复制因子）
• x-max-in-memory-length=0

x-max-in-memory-length 属性强制法定人数队列在安全的情况下立即从内存中删除消息正文。您可以将其设置为更长的限制，这是最激进的设置 - 旨在避免在消费者无法跟上的情况下内存大幅增长，代价是在消费者无法跟上的情况下进行更多磁盘读取。如果没有此属性，消息正文将始终保留在内存中，这会导致内存增长到内存警报触发的地步，从而严重影响发布率 - 在此工作负载案例研究中我们希望避免这种情况。