RabbitMQ 4.1 性能改进
RabbitMQ 4.1 即将发布,与往常一样,除了新功能外,我们还进行了一些内部更改,这些更改应提供更好的性能。
至少有 4 个值得注意的更改
- 仲裁队列更低且更稳定的内存使用量
- 消费长仲裁队列时性能更好
- Websocket 连接的性能更好
- TCP 连接的内存使用量更低和/或吞吐量更高
RabbitMQ 4.1 即将发布,与往常一样,除了新功能外,我们还进行了一些内部更改,这些更改应提供更好的性能。
至少有 4 个值得注意的更改
这篇博文概述了 AMQP 1.0 流控制相对于 AMQP 0.9.1 的十个优势,并辅以两个基准测试,证明了性能的显着提升。此外,我们深入研究了强大的 AMQP 1.0 流控制原语以及它们在 RabbitMQ 中的使用方式。
这篇博文证明,与 RabbitMQ 3.13 中的 AMQP 1.0 相比,RabbitMQ 4.0 中的原生 AMQP 1.0 提供了显着的性能和可扩展性改进。
此外,这篇博文表明,在 RabbitMQ 4.0 中,AMQP 1.0 的性能可能略优于 AMQP 0.9.1。
RabbitMQ 3.12 即将发布,其中包含许多新功能和改进。这篇博文重点介绍与性能相关的差异。最重要的变化是经典队列的 lazy
模式现在是标准行为(更多内容见下文)。新的实现应该更节省内存,同时提供比早期版本中的 lazy
或 non-lazy
实现更高的吞吐量和更低的延迟。
为了获得更好的性能,我们强烈建议切换到经典队列版本 2 (CQv2)。
RabbitMQ 的核心协议一直是 AMQP 0.9.1。为了支持 MQTT、STOMP 和 AMQP 1.0,broker 通过其核心协议透明地代理。虽然这是一种使用更多消息传递协议扩展 RabbitMQ 支持的简单方法,但它会降低可扩展性和性能。
在过去的 9 个月中,我们重写了 MQTT 插件,使其不再通过 AMQP 0.9.1 代理。相反,MQTT 插件解析 MQTT 消息并将其直接发送到队列。这就是我们所说的原生 MQTT。
结果非常惊人
原生 MQTT 将 RabbitMQ 变成一个 MQTT broker,为更广泛的 IoT 用例打开了大门。
原生 MQTT 在 RabbitMQ 3.12 中发布。
最近的 Erlang/OTP 版本附带 Linux perf 支持。这篇博文提供了关于如何在 RabbitMQ 中创建 CPU 和内存火焰图以快速准确地检测性能瓶颈的分步说明。我们还提供了火焰图如何帮助我们提高 RabbitMQ 中的消息吞吐量的示例。
RabbitMQ 3.10 于 2022 年 5 月 3 日发布,其中包含许多新功能和改进。这篇博文概述了该版本中的性能改进。简而言之,您可以期望更高的吞吐量、更低的延迟和更快的节点启动速度,尤其是在启动时导入大型定义文件的情况下。
在上一篇文章中,我们开始对使用仲裁队列的工作负载进行大小调整分析。我们专注于消费者保持同步的理想情况,这意味着没有队列积压,并且集群中的所有 broker 都在正常运行。通过运行一系列基准测试,模拟不同强度的工作负载,我们确定了每 1000 msg/s 每月成本排名前 5 的集群大小和存储卷组合。
还有更多测试要运行,以确保这些集群可以处理 broker 故障以及在中断或系统速度减慢等情况下累积的大量积压。
所有仲裁队列都使用以下属性声明
x-max-in-memory-length 属性强制仲裁队列在安全时立即从内存中删除消息体。您可以将其设置为更长的限制,这是最激进的 - 旨在避免大型内存增长,但代价是当消费者跟不上时需要进行更多磁盘读取。如果没有此属性,消息体将始终保留在内存中,这可能会导致内存增长到触发内存警报的程度,从而严重影响发布速率 - 这是我们希望在本工作负载案例研究中避免的情况。