Rabbitmq-合理的性能/规模期望

13

如果有人能指出我对Rabbitmq的合理比例数字/限制（关于“平均”硬件，fwiw）或发表其性能的经验，我将不胜感激。我正在尝试了解队列数量，队列上的订户数量，扇出队列上有成百上千个侦听器的性能影响，任何硬数字在任何人都可能在大容量环境中运行Rabbit的能力。

performance rabbitmq

— 用户名
source

这非常容易测试，特别是考虑到您期望的数量，您有预算准备一些虚拟机。我强烈建议您根据您的确切用例，您希望使用的硬件进行测试。

— Andrew M.

查看CloudAMQP的计划-这些是针对某些硬件配置的经过测试的性能数字。

— 恢复莫妮卡-M.Schröder'16

11

首先，您需要了解列表中的哪些项目具有可能达到的缩放限制，而哪些没有。其中一些是依赖于实现的，因此有助于阅读内部内容，例如《 RabbitMQ in Action》一书。

队列数受您的RAM限制。另一方面，正在播放的消息数不受RAM的限制，因为RabbitMQ自动将它们分页到磁盘。当我不注意的时候，在开发服务器上意外播放了将近800万条消息。

消息的大小也没有限制，但是如果单个消息的大小超过512K，则您确实应该三思。我最终使用内存缓存在应用程序之间传递大型对象，只发送了包含memcache键的较小控制消息。但是，如果您确实愿意，则可以将巨大的JPEG和二进制对象（例如JAR文件）作为消息发送。

订阅者数量是OS限制，因为订阅者需要至少打开一个TCP套接字。当然，这在大多数操作系统中都是可调的，因此您的工作量会有所不同，这就是为什么必须测试模型的原因。我一直在使用JMETER对我们的Web应用程序进行负载测试，而我刚刚发现了这个AMQP插件https://github.com/jlavallee/JMeter-Rabbit-AMQP，但尚未使用它。无论如何，这是一种可以快速告诉您硬件（或VM配置）将进行合理处理的测试。

您唯一困难的事情是测试扇出队列中的大量使用者。您可能还想与使用主题交换的用户进行比较，而消费者使用通配符（*）的绑定密钥进行预订，从而获得相同的最终结果。尝试在尽可能多的不同机器上运行此测试，以确保不会因单一服务器运行使用者进程而造成瓶颈。PS Jmeter插件看起来对模拟消费者也可能有用。

— 迈克尔·狄龙
source

6

这不是一个真正可以回答的问题-有太多因素（“平均”硬件的移动定义，队列中消息的大小，使用者的数量以及它们轮询的频率/完成消息的速度等））。您确实需要对环境进行基准测试。

也就是说，请查看以下有关RabbitMQ性能的讨论（包括一些有关如何对安装进行基准测试以了解对Rabbit的期望的想法）：

— voretaq7
source

1

我知道很多变量。这就是为什么我在引用中提到“平均”硬件之类的原因，因为我了解一个想法有多模糊。不过，我认为从人民的经验中得出的一些数字将是有用的。感谢您的参考。

— user21640

1

@ user21640不仅仅是硬件使您的问题更加模糊-高频交易与您或我的“高容量”概念可能有所不同，并且可接受性能的定义也大不相同。最后的唯一的人，其经验重要的是你，在你的环境中，在我的经验一个精心策划的本地基准是价值数千外部报告，当谈到在容量规划的信心-你永远不知道什么时候你的工作量的病理情况： -）

— voretaq7'4