29 篇标记为“performance”的帖子

RabbitMQ Streams 专为高吞吐量场景而设计，但当您的入口速率较低时会发生什么？较低的消息速率会严重影响交付性能，使消息消耗速率降低一个数量级。RabbitMQ 4.2 引入了一项优化，可显著提高低吞吐量流的交付速率，使所有支持的协议都受益。

RabbitMQ 4.1 即将发布（更新：已发布），并且一如既往，除了新功能之外，我们还进行了一些内部改进，以提供更好的性能。

至少有 4 项值得注意的改进

1. 仲裁队列的内存使用率更低且更稳定
2. 消费长仲裁队列时性能大幅提升
3. WebSocket 连接性能更佳
4. TCP 连接内存使用率更低和/或吞吐量更高

这篇博客文章概述了 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.0 版本
• 支持流过滤

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

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

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 Operator、Docker 社区镜像和 VMware Tanzu RabbitMQ for VMs 的现代版本的用户不受影响，因为这些项目目前都使用 Erlang 23