Rabbitmq 性能测试

背景:

线上环境,出了一起事故,初步定位是rabbitmq server。

通过抓包发现,是有多个应用使用同一台rabbitmq server。并且多个应用使用rabbitmq的方式也不一样。发现有以下两种方式:

1. 每次produce 一条消息,开闭channel一次

2. 每次produce 一条消息,开闭connection一次,开闭channel一次。

这种使用方法是我们怀疑的一个点,除此之外还有怀疑的点有:

1. rabbitmq cluster的配置问题

2. rabbitmq server的硬件问题(体现在磁盘的io_wait 升高,tcp连接数的上升)

3. rabbitmq 本身的问题?

4. 网络抖动和网络延迟?

 

因为可能性比较多,所以,做一次全面的评估和定位还是有必要的。

有些任务交给IT和运维去追踪了。我这边主要负责一下客户端使用方式的评估

目标:

1. 确认使用两种使用方法(见上文),是否会造成瓶颈?

2. 确认两种使用方法,在什么情况下会出问题?是否会百分百可以重现?

从理论上,rabbitmq文档,以及抓包数据来说:每条消息开关一次connection 必然是效率最低的。

试想一下,每条消息体,需要建立和关闭一条tcp连接,中间还要掺杂着AMQP的控制报文,多么的浪费资源!!!!

简单的测评结果如下:

 
方法描述 高峰消息量 参数 备注
共用一个connection,每条消息开关一次channel。 2000msg/s 1个线程,无消费者 使用本机Rabbitmq,本地java client
每条消息开关一次connection 200msg/s 1个线程,无消费者 使用本机Rabbitmq,本地java client

 

 

 

 

 

 

上面这个结果是一个简单的测试结果。

在尝试混合使用两种模式访问本地rabbitmq的时候,出现了一下问题。问题也很奇怪,有一个方法的进程启动后,另外一种就会SocketTimeout。

 

后面只好在测试环境找了台Rabbitmq Server。

然后google了一把,原来有个jmeter-rabbitmq-plugin。太帅了。功能不全是自己要的,没关系,改呗。代码参见:https://github.com/lykm02/JMeter-Rabbit-AMQP 。(我更新了maven build 方式和一些jar version信息,在branch support_maven_xx 上)

放到jmeter中,就可以使用jmeter来压了。

结论是:确实connection的使用方式 会影响到rabbitmq的内部,从而导致其他连接到同一rabbitmq的连接收到影响。

具体工作原理,因为涉及到rabbitmq的源码,目前没有深入研究。

 

posted @ 2016-07-31 00:07  风云力  阅读(13790)  评论(1编辑  收藏  举报