前言
下面关注一下rabbitmq实际使用时的性能问题和怎么进行一些优化。
性能测试
针对每个需要生产/消费者与rabbitmq进行通讯的方法进行测试
测试环境
-
排除网络IO的干扰,采用生产者和消费者都在本地服务器的方式
-
内存16G,CPU4核,3.1GHZ
-
操作系统:oracle-linux
-
python版本:3.6.3
测试内容
-
创建10万个connection连接的平均速度
-
创建10万个信道的平均速度
-
创建10万个相同队列的平均速度
-
创建10万个相同直连交换机的平均速度
-
创建10万个相同主题交换机的平均速度
-
创建10万个交换机和队列绑定的平均速度
-
投递10万条10字节消息的的平均速度
-
投递10万条300K消息的的平均速度
测试使用的脚本
- 下载地址:rabbitmq对pika的性能测试
测试结果
connection连接:单线程496/s,多线程最大750/s
信道创建:单线程800/s,多线程850/s;
队列创建:单线程3867/s,多线程3300/s
交换机创建:单线程3900/s,多线程3250/s
绑定创建:单线程2700/s,多线程2500/s
10字节消息投递速度:10300msg/s
300k消息传递:2400msg/s
总结
-
可以看到信道的创建速度高于tcp连接,所以一般保持TCP连接而使用多个channel;
-
对于业务来说,一般是客户端请求服务器提交数据,服务器连接rabbitmq存储数据,那么服务器可以先创建tcp长连接池或channel信道池,到可以提交数据后,服务器直接调用连接对象传递数据。
-
队列和交换机一般是设置持久化的,它们可以长期存在,而消费者也是预先定义的,可以将队列的声明,交换机声明,绑定放在消费者端;
-
生产和消费同时消耗rabbitmq的资源,当生产消费不平衡,如生产大于消费造成消息堆积时,消费者的消费速度回随着内存的减小变慢,可能造成性能的急剧恶化;
测试发现的一个问题
使用pika操作rabbitmq,在创建信道池后,如果一段时间rabbitmq的tcp连接没有接受到请求,其会强制关闭tcp连接,造成信道池不可用,所以需要重新开启TCP连接;