前言
下面关注一下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连接；