测试结果
4.1队列发送性能结果
4.1.1
单线程发送100万消息(1 X 100万)
采样序号 | 发送速率 | 上传大小 | 消耗时 | 带宽利用率 |
1 | 8745msg/s | 1.16G | 114.44s | 79.3% |
2 | 8696msg/s | 1.16G | 114.958s | 78.7% |
3 | 8598.6msg/s | 1.16G | 116.297s | 77.3% |
采样1服务器端CPU、IO及网络消耗
采样2服务器端CPU、IO及网络消耗
采样3服务器端CPU、IO及网络消耗
4.1.2 5线程发送500万消息(5 X 100万)
采样序号 | 发送速率 | 上传大小 | 消耗时 | 带宽利用率 |
4 | 8155.56msg/s | 5.34G | 613.078s | 73% |
5 | 8656.36msg/s | 5.34G | 612.35s | 72.8% |
采样4服务器端CPU、IO及网络消耗
采样5服务器端CPU、IO及网络消耗
4.1.3 10线程发送1000万消息(10 X 100万)
采样序号 | 发送速率 | 上传大小 | 消耗时 | 带宽利用率 |
6 | 8271.08msg/s | 11.47G | 1209.031s | 74.6% |
采样6服务器端CPU、IO及网络消耗
4.1.5 发送性能小结
Ø 在使用异步发送模式下5线程发送消息可以利用客户端75%左右的网络带宽,其发送速率达最快达到8656.36Msgs/s;
Ø 服务器端可利用70%到75%的网络带宽用于从发送客户端读取数据,CPU消耗最多10%左右,IO在12000左右
4.2队列接收性能结果
4.2.1单线程接收100万消息(1 X 100万)
采样序号 | 接收速率 | 下载大小 | 消耗时 | 带宽利用率 |
7 | 6203msg/s | 1.16G | 180s | 75.2% |
8 | 6037msg/s | 1.16G | 190s | 72.3% |
采样7服务器端CPU、IO及网络消耗
采样8服务器端CPU、IO及网络消耗
4.2.2 2消费者接收500万消息(2X 250万)
采样序号 | 接收速率 | 下载大小 | 消耗时 | 带宽利用率 |
9 | 6732msg/s | 5.34G | 850s | 68% |
采样9服务器端CPU、IO及网络消耗
4.2.3 5消费者接收500万消息(5 X 100万)
采样序号 | 接收速率 | 下载大小 | 消耗时 | 带宽利用率 |
10 | 5050msg/s | 5.5G | 933s | 65.3% |
采样10服务器端CPU、IO及网络消耗
4.2.4 10消费者接收1000万消息(10X100万)
采样序号 | 接收速率 | 下载大小 | 消耗时 | 带宽利用率 |
11s | 5254msg/s | 10.56G | 1903s | 67.3% |
采样11服务器端CPU、IO及网络消耗
4.2.5接收性能小结
Ø 在使用异步接收模式,消费者的消费性能在5000msg/s~6500msg/s之间。
Ø 依据测试在异步接收消费者的个数为2,消费者的性能达到最佳6732msg/s
Ø 增加消费者,并不能快速的消费发送的数据,受到网络环境(带宽)与IO的影响。
4.3发送接收性能结果
4.3.1单线程发送2消费者线程接收100万消息(1X100万)
采样序号 | 发送速率 | 接收速率 | 带宽利用率 |
12 | 5480msg/s | 5520msg/s | 55% |
13 | 5601msg/s | 5734msg/s | 57% |
采样12服务器端CPU、IO及网络消耗
采样13服务器端CPU、IO及网络消耗
4.3.2 5线程发送5消费者线程接收500万消息(5X100万)
采样序号 | 发送速率 | 接收速率 | 带宽利用率 |
14 | 6650msg/s | 6360msg/s | 64.8% |
15 | 6540msg/s | 5989msg/s | 62.6% |
采样14服务器端CPU、IO及网络消耗
采样15服务器端CPU、IO及网络消耗
4.4发送数据宕机结果
采样序号 | 发送总量 | 宕机次数 | 接收总量 | 丢失率 |
16 | 1000万 | 3 | 9999492 | 0.00508% |
17 | 500万 | 2 | 4999583 | 0.00827% |
18 | 100万 | 1 | 999798 | 0.00202% |
4.5队列消息恢复结果
采样序号 | 消息总数 | 恢复时间 |
|
19 | 100万 | 15s |
|
20 | 500万 | 45s |
|
21 | 1000万 | 150s |
|
4.6增加集群节点结果
采样序号 | 发送消息 | 增加节点个数 | 接收消息 |
22 | 100万 | 1 | 100万 |
23 | 500万 | 1 | 500万 |
4.7删除集群节点结果
采样序号 | 发送消息 | 删除节点个数 | 接收消息 |
24 | 100万 | 1 | 100万 |
25 | 500万 | 1 | 500万 |
5. 测试总结
Ø 根据本次的测试结果,100MB网络中,二台rabbitmq做集群,生产者,使用异步模式发送数据比同步模式速度快了18倍。发送者速率达到8696msg/s 接收者速率达到6732msg/s 所占用CPU为8%~12%.
Ø 生产者使用多线程发送数据到queue三到五个线程性能发送最佳,超过它也不能提高生产的发送速率。
Ø 消费者的数据处理,使用二线程接收性能是最佳的,如数据处理程序处理比较复杂的逻辑,建议多开启几个线程进行数据接收。
Ø 在发送接收队列中,因为发送的速率总比接收的速率要快,因此考虑在接收端配置比发送端更多的线程,个人认为:
接收者线程 = 发送者线程 X 1.5
Ø RabbitMq在做数据恢复时,遇到过一次数据恢复不了后就没有办法复现。数据恢复的时间会随着数据量的大小成直线增长。
Ø 集群中持久化的数据保存在客户端所连接的这个节点,而其它节点都会对这数据进行镜像,从而保证各节点队列的数据一致。
Ø 集群中增加节点对整个集群没有影响,但删除节点只有在一种情况下会有影响就是此节点有生产者进行生产数据,会导致部分数据丢失。
Ø RabbitMq是erlang 语言所写,集群环境与erlang的集群环境关系非常紧密,稍有配置不正确,集群环境搭建不成功。
Ø 集群环境中对IO的操作是比较大的(12000左右)IO大的原因是因为将队列中的消息进行了持久化操作,非持久化的队列IO操作大概在140/s~180/s
Ø 在rabbitMq2.7.0版本中,提供了部分插件(UI),来监控rabbitMq中的clientconnect、exchange 、vhost、queue、binding 、发送速率、接收速率等。
使用RabbitMQ的一些经验教训:(源文章:http://www.cnblogs.com/liuhao/archive/2012/12/14/2818633.html)
- 提供c++客户端时,限制使用接口,只保留了publish\consume\ack,保证业务使用时可以有极低的学习成本;
- consume时预取参数的大小对consume性能影响很大,具体可参见官方博客;
- 队列HA的代价非常高,特别是对带宽的占用,有限制的使用HA,且只提供两备份即可;
- 磁盘也可能形成瓶颈,如果单台机器队列很多,确认只在必要时才使用duration,避免把磁盘跑满;
- 队列的消息大量累积后,发送和消费速度都会受到影响,导致服务进一步恶化,采用的方法是,额外的脚本监控每个队列的消息数,超过限额会执行purge操作,简单粗暴但是有效的保证了服务稳定;
- 限制单条消息大小,我们的限制是128k,消息队列只走消息,其他交由存储去做;
- 用iptables适当的限制连接;
源文章:http://www.xuebuyuan.com/1281113.html