Rabbit测试及其方案

转载:https://www.2cto.com/kf/201609/548190.html

个消息没有回应,则MQ不会再往消费者A中发消息,直到收到消息确认后才会再次发送。

Ack:消息确认。

:启动一个生产者,无消费者。

Rabbit测试及其方案

条消息,磁盘写入是6250/s

当消息的堆积量达到40W以上时,每秒进入队列的速率就会降到4500~5000/s之间

 
 

:启动三个生产者,无消费者。

Rabbit测试及其方案

 
 

条消息,磁盘写入是6500/s

 
 

:启动10个生产者,无消费者

Rabbit测试及其方案

 
 

条消息,磁盘写入是7300/s

 
 

:启动20个生产者,无消费者

Rabbit测试及其方案

 
 

个生成者是8500,经过反复测试最终发现20~25个生产者效率最高。

 
 

个消费者,Qos为0,默认ack接收到消息马上返回。

Rabbit测试及其方案

Rabbit测试及其方案

测试结果:每秒消费8000Qps

 
 

:启动无生产者,1个消费者,Qos为1,默认应答接收到消息马上返回。

Rabbit测试及其方案

Rabbit测试及其方案

测试结果:每秒消费310Qps;

 
 

:启动无生产者,1个消费者,Qos为1,默认不应答接收到消息马上返回

Rabbit测试及其方案

 
 

Rabbit测试及其方案

测试结果:每秒消费11500Qps;

 
 

:启动无生产者,一个消费者,Qos为10,默认ack接收到消息马上返回。

 
 

Rabbit测试及其方案

Rabbit测试及其方案

 
 

:启动1个生产者,1个消费者,Qos为10,默认Ack,接收到消息后马上返回。

Rabbit测试及其方案

 
 

测试结果:生成4000Qps/s消费1000Qps/s

 
 

:启动1个生成者,1个消费者,Qos为10,默认Ack,接收到消息休眠10ms

Rabbit测试及其方案

 
 

测试结果:生产4500Qps/s消费10Qps/s

 
 

:启动1个生产者,1个连接,10个消费者,Qos为100,默认Ack,接收到消息休眠10ms

Rabbit测试及其方案

 
 

测试结果:生产5000qps/s消费500qps/s

这说明一味的增加channel开启consumer应该是有瓶颈的,随着consumer的增加,消费效率应该也不会有太大的增加,接着测试

 
 

:启动一个生产者,1个连接,30个消费者,Qos为100,默认Ack,接收到消息休眠10ms

Rabbit测试及其方案

测试结果:生产4500qps/s消费450qps/s

左右,感觉要到瓶颈了.后面我尝试过consumer_size=50,也是这个值,直到consumer_size=17的时候就是500/s,再增加consumer也不会增加效率了.

从数据上来看感觉是一个连接里面channel有一个上限值,再多也处理不完了,那可以考虑尝试增加connection来试试是否能够增加消费能力

 
 

:启动1个生产者,3个连接,每个连接里面创建17个消费者,Qos为100,默认Ack,接收到消息休眠10ms,用来模拟业务处理时间

Rabbit测试及其方案

 
 

测试结果:生产4320qps/s消费1500qps/s

:启动一个生产者,10个连接,每个连接里面创建17个消费者,Qos为100,默认Ack,接收到消息休眠10ms,用来模拟业务处理时间

 
 

总结

通过以上的测试,我们基本上得出以下几个结论:

1.生产者生产消息过快,无论是否有消费者,都会触发流控,不同的是流控强度随消费者个数加强.

2.一旦有消费者连接,就会对生产者的消息生产效率产生影响(在触发流控之后)

3.在每个连接里面在创建相应数量的consumer,可以增加消费能力,但是也是有上限的,我的
测试中上限是17

4.创建多个连接,并且每个每个连接里面consumer设置到上限数量,可以进一步增加消费能力

5.在消息堆积的情况下,消费者数量与生产者的生产效率成反比

6.在没有消息堆积的情况下,设置得当的话,基本上可以做到生产与消费同步(测试的最大值为13000+/s,加大连接数可能还会提高)

上一篇:sql server: 最短路径


下一篇:js排序问题