跳到主要内容

关于“性能”的 28 篇文章

查看所有标签

RabbitMQ 4.1 性能改进

·5 分钟阅读

RabbitMQ 4.1 即将发布,与往常一样,除了新功能外,我们还进行了一些内部更改,这些更改应提供更好的性能。

至少有 4 个值得注意的更改

  1. 仲裁队列更低且更稳定的内存使用量
  2. 消费长仲裁队列时性能更好
  3. Websocket 连接的性能更好
  4. TCP 连接的内存使用量更低和/或吞吐量更高

RabbitMQ 3.12 性能改进

·13 分钟阅读

RabbitMQ 3.12 即将发布,其中包含许多新功能和改进。这篇博文重点介绍与性能相关的差异。最重要的变化是经典队列的 lazy 模式现在是标准行为(更多内容见下文)。新的实现应该更节省内存,同时提供比早期版本中的 lazynon-lazy 实现更高的吞吐量和更低的延迟。

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

使用原生 MQTT 服务数百万客户端

·24 分钟阅读

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

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

结果非常惊人

  1. 在许多连接的情况下,内存使用量最多可降低 95% 和数百 GB。
  2. 有史以来第一次,RabbitMQ 能够处理数百万个连接。
  3. 端到端延迟降低 50% - 70%。
  4. 吞吐量增加 30% - 40%。

原生 MQTT 将 RabbitMQ 变成一个 MQTT broker,为更广泛的 IoT 用例打开了大门。

原生 MQTT 在 RabbitMQ 3.12 中发布。

Erlang 24 支持路线图

·5 分钟阅读

TL;DR

  • Erlang 24 将于 5 月发布,它为 RabbitMQ 用户提供了显着的性能提升
  • 同时支持 Erlang 24 和 22 是不可行的,因此在 2021 年 5 月初,将停止对 Erlang 22 的支持
  • 如果您在 Erlang 22 上运行,请立即升级到 23.2:它应该是直接替换
  • RabbitMQ Kubernetes OperatorDocker 社区镜像和最新版本的 VMware Tanzu RabbitMQ for VMs 的用户不受影响,因为这些项目今天都使用 Erlang 23

集群大小调整案例研究 – 仲裁队列第 2 部分

·12 分钟阅读
Jack Vanlightly

上一篇文章中,我们开始对使用仲裁队列的工作负载进行大小调整分析。我们专注于消费者保持同步的理想情况,这意味着没有队列积压,并且集群中的所有 broker 都在正常运行。通过运行一系列基准测试,模拟不同强度的工作负载,我们确定了每 1000 msg/s 每月成本排名前 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 美元

还有更多测试要运行,以确保这些集群可以处理 broker 故障以及在中断或系统速度减慢等情况下累积的大量积压。

所有仲裁队列都使用以下属性声明

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

x-max-in-memory-length 属性强制仲裁队列在安全时立即从内存中删除消息体。您可以将其设置为更长的限制,这是最激进的 - 旨在避免大型内存增长,但代价是当消费者跟不上时需要进行更多磁盘读取。如果没有此属性,消息体将始终保留在内存中,这可能会导致内存增长到触发内存警报的程度,从而严重影响发布速率 - 这是我们希望在本工作负载案例研究中避免的情况。

© . All rights reserved.