使用 RabbitMQ 3.3 查找瓶颈
RabbitMQ 3.3 的目标之一是让您更容易地在运行系统中找到瓶颈。早期版本的 RabbitMQ 允许您看到您受到了速率限制，但没有让您轻松地看到原因。在本博文中，我们将讨论 3.3 版本中的一些新的性能指标。
了解流控制
自从在 RabbitMQ 2.8.0 中引入流控制以来，您就可以看到连接何时进入流控制状态。这意味着（大致）客户端受到速率限制；它希望更快地发布，但服务器跟不上。当然，您要问的下一个问题是“为什么？”。
流控制机制一直扩展到整个服务器；不仅连接，通道和队列也可以处于流控制状态，这意味着它们希望更快地发布消息，但它们前面的某些东西跟不上。因此，要理解新的流控制信息，您需要知道 **如果任何组件发布的内容是瓶颈，或者它本身处于流控制状态，则该组件将进入流控制状态**。组件在进入服务器时处理消息的顺序是
网络
↓
连接进程 - AMQP 解析，通道多路复用
↓
通道进程 - 路由，安全，协调
↓
队列进程 - 内存中消息，持久队列索引
↓
消息存储 - 消息持久化
那么有哪些可能的结果呢？
- 连接处于流控制状态，但其任何通道都不处于流控制状态 - 这意味着一个或多个通道是瓶颈；服务器在通道所做的某些操作上是 CPU 密集型，可能是路由逻辑。这最有可能出现在发布小的瞬态消息时。
- 连接处于流控制状态，其一些通道处于流控制状态，但它发布到的任何队列都不处于流控制状态 - 这意味着一个或多个队列是瓶颈；服务器在接受进入队列的消息时是 CPU 密集型，或者在将队列索引写入磁盘时是 I/O 密集型。这最有可能出现在发布小的持久消息时。
- 连接处于流控制状态，其一些通道处于流控制状态，其发布到的队列也处于流控制状态 - 这意味着消息存储是瓶颈；服务器在将消息写入磁盘时是 I/O 密集型。这最有可能出现在发布较大的持久消息时。
消费者利用率
因此，希望您现在能够更好地了解服务器发布端的性能。那么消费端呢？流控制机制没有扩展到消费者，但我们确实有一个新的指标可以帮助您了解消费者的工作强度。
该指标是消费者利用率。消费者利用率的定义是队列消费者能够接收新消息的时间比例。因此，它是一个介于 0 到 1 之间的数字，或者 0% 到 100%（如果队列没有消费者，则为 N/A）。因此，如果队列的消费者利用率为 100%，那么它永远不需要等待消费者；它总是能够以它所能达到的最快速度将消息推送到消费者。
如果其利用率低于 100%，则意味着其消费者有时无法接收消息。网络拥塞会限制您所能达到的利用率，或者低利用率可能是由于使用了过低的 预取限制 导致的，这会导致队列在消费者处理消息之前需要等待，直到它能够发送更多消息。
下表显示了我观察到的在 localhost 上使用单个消费者消费微小消息时的消费者利用率的一些近似值
| 预取限制 | 消费者利用率 |
|---|---|
| 1 | 14% |
| 3 | 25% |
| 10 | 46% |
| 30 | 70% |
| 1000 | 74% |
您可以看到，利用率随着预取限制的增加而增加，直到我们达到约 30 的限制。之后，网络带宽限制开始占主导地位，增加限制不再有任何益处。因此，您可以看到，消费者利用率是监控消费者性能的一种简单方法。
了解更多
- 网络研讨会：RabbitMQ 3.8 中有哪些新功能？
- 网络研讨会：每个使用 RabbitMQ 的开发人员都应该知道的 10 件事
进程已完成，退出代码为 0