29 篇标记为“performance”的帖子

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

1. 集群：7 个节点，8 个 vCPU (c5.2xlarge)，gp2 SSD。成本：54 美元
2. 集群：9 个节点，8 个 vCPU (c5.2xlarge)，gp2 SSD。成本：69 美元
3. 集群：5 个节点，8 个 vCPU (c5.2xlarge)，st1 HDD。成本：93 美元
4. 集群：5 个节点，16 个 vCPU (c5.4xlarge)，gp2 SSD。成本：98 美元
5. 集群：7 个节点，16 个 vCPU (c5.4xlarge)，gp2 SSD。成本：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 属性强制仲裁队列在安全时尽快将消息体从内存中移除。您可以将其设置为更长的限制，这是最激进的设置——旨在避免内存大幅增长，但代价是在消费者跟不上时增加磁盘读取次数。没有此属性，消息体将始终保留在内存中，这可能导致内存增长到触发内存警报，严重影响发布速率——这是我们在本次工作负载案例研究中希望避免的。

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

1. 集群：5 节点，8 vCPU，gp2 SSD。成本：58 美元
2. 集群：7 节点，8 vCPU，gp2 SSD。成本：81 美元
3. 集群：5 节点，8 vCPU，st1 HDD。成本：93 美元
4. 集群：5 节点，16 vCPU，gp2 SSD。成本：98 美元
5. 集群：9 节点，8 vCPU，gp2 SSD。成本：104 美元

还需要进行更多测试，以确保这些集群能够处理代理程序故障和因停机或系统减速而积压大量消息的情况。

在本系列规模分析的第一篇文章中，我们讨论了AWS EC2上的工作负载、集群和存储卷配置。在本文中，我们将进行镜像队列的规模分析。

我们规模分析的第一阶段将评估我们每个集群和存储卷能够轻松处理的负载强度，以及哪些负载过高。

所有测试均使用以下策略

• ha-mode: exactly
• ha-params: 2
• ha-sync-mode: manual

这是我们开始查看 RabbitMQ 集群容量规划的短系列文章的开篇。实际容量规划完全取决于您的硬件和工作负载，因此，我们不会告诉您应该配置多少 CPU 和多少 RAM，而是会制定一些通用指南，并使用案例研究来展示您应该考虑的事项。

进行基准测试可能有很多原因

• 容量规划和容量管理
• 产品评估（RabbitMQ 能否处理我的负载？）
• 发现适合您工作负载的最佳配置

在本文中，我们将介绍运行 RabbitMQ 基准测试的各种选项。但在我们开始之前，您需要一种查看结果和查看系统指标的方法。

在 上一篇文章 中，我们对单个队列进行了一些简单的基准测试，以了解管道化发布者确认和消费者确认对流量控制的影响。

具体来说，我们研究了

• 发布者：限制正在进行的消息数量（已发送但等待确认的消息）。
• 消费者：预取（代理程序允许在通道上传输的消息数量）
• 消费者：确认间隔（多标志用法）

不出所料，我们发现当我们将发布者和代理程序限制为一次少量正在进行的消息时，吞吐量较低。当我们增加这个限制时，吞吐量有所提高，但仅限于某个点，之后我们没有看到吞吐量进一步提升，反而只是延迟增加。我们还发现允许消费者使用多标志对吞吐量有利。

在本文中，我们将针对许多客户端、许多队列以及不同量的负载（包括压力测试）来查看这三个相同的设置。我们将看到发布者确认和消费者确认在流量控制中起作用，以帮助防止代理程序过载。

在上一篇文章中，我们介绍了流量控制的概念，以及 RabbitMQ 中可用的各种流量控制机制。我们看到，发布者确认和消费者确认不仅仅是数据安全措施，它们在流量控制中也起着作用。 

在本文中，我们将探讨应用程序开发人员如何在单个队列的上下文中，利用发布者确认和消费者确认来平衡安全性和高性能。 

当代理过载时，流量控制尤其重要。单个队列不太可能使您的代理过载。如果您发送大消息，那确实可以使您的网络饱和，或者如果您只有一个 CPU 核心，那么一个队列可能会使其达到最大利用率。但我们大多数人使用的都是 8、16 或 30+ 核心的机器。但是，分析确认和确认对单个队列的影响是很有趣的。从那里，我们可以吸取经验教训，看看它们是否适用于更大的部署（下一篇文章）。

作为我们仲裁队列系列的一部分，我们将深入探讨流量控制，了解它如何保护 RabbitMQ 免受过载影响，以及它与仲裁队列的关系。

什么是流量控制？​

流量控制是一个在计算机网络和网络软件中存在了数十年的概念。本质上，它是一种机制，通过向发送方施加反压来避免接收方过载。接收方通常会将传入的数据包/消息缓冲起来，以应对发送速率超过其处理速率的情况。但接收方缓冲区不能无限增长，因此发送速率只能暂时超过接收方的处理能力（突发流量），或者必须减缓发送方的速度（反压）。

流量控制是一种对发送方施加这种反压的方法，减缓它们的发送速度，以防止接收方的缓冲区溢出并避免延迟过大。在一个发送方/接收方的链条中，这种反压可以沿着链条向上传播到流量的源头。在更复杂的连接组件图中，流量控制可以在快速和慢速发送方之间平衡传入流量，避免过载，同时允许系统在发送方数量、速率和负载模式（稳定或突发）不同时达到充分利用。

仲裁队列在 RabbitMQ 中相对较新，许多人尚未从经典镜像队列迁移到仲裁队列。在迁移到这种新队列类型之前，您需要确保您的硬件能够支持您的工作负载，而存储驱动器是其中的一个重要因素。

在这篇博文中，我们将更仔细地探讨仲裁队列及其在不同存储配置下的性能特征。

HDD 还是 SSD？一个驱动器还是多个驱动器？​

简而言之，我们强烈建议在使用仲裁队列时使用 SSD。原因是仲裁队列对 IO 延迟敏感，而 SSD 提供的 IO 延迟比 HDD 低。IO 延迟较高会导致吞吐量较低、端到端延迟较高以及其他一些不良影响。

在本文的后面，我们将通过使用各种 SSD 和 HDD 配置的基准测试来演示我们推荐此建议的原因。