原文:http://my.oschina.net/zookeeper/blog/186667
设置场景
设置场景

场景A:入队列20000条消息,每条1K,然后出队列
场景B:同时入队列、出队列20000条消息,每条1K
场景C:同时入队列、出队列20000条消息,每条32字节
场景D:同时入队列、出队列200条消息,每条32M
一个进程专注于入队,一个进程专注于出队
我会衡量两种配置状态下的每个入队出队的耗时
1)使用持久化队列(队列进程重启后数据状态)
2)使用非持久化队列
测试以下队列:
ActiveMQ 5.8.0:STOMP协议
RabbitMQ 3.0.2:STOMP协议和AMQP协议
HornetQ 2.3.0:STOMP协议
Apollo 1.6:STOMP协议
QPID 0.20:AMQP协议
注:
STOMP:一个简单的消息文本协议,它的设计核心理念就是简单与可用性
AMQP:高级消息队列
协议,是应用层
协议的一个开放标准,为面向消息的中间件设计
硬件环境:
-
CPU: Intel Core i3 @ 2.40 GHz
-
RAM: 4 Gb
-
OS: Windows 7 64 bits
-
Ruby 1.9.3p392
-
Java 1.7.0_17-b02
相同的持久化设置,其余为默认配置,以下为测试结果
场景A:(时间越少越好)

场景B:(时间越少越好)

场景C:(时间越少越好)

场景D:(时间越少越好)

结语:
测试很简单(1台主机,出入队列各一个,没有指定调优),结果会给我们一个大致的性能估算,更多复杂的场景将需要更多复杂的设置,不管怎样我们会观察到一些趋势:
1)在消息包很大的情况下所有的broker都运转正常。因此如果你的队列客户端支持分组消息就很好,否则被分组的消息不会被并行执行的消费者获取
2)持久化的缺陷在处理大型消息包时候呈现出来,这说明小的消息包时间花费在处理而不是I/O
3)QPID好像在非持久化中成绩最好
4)好像AMQP协议比STOMP有效率(至少使用该协议的rabbitmQ的表现是这样的)。
5)HornetQ在中等数据包的表现比其它的差
6)除了打消息包,RabbitMQ有着表现最好的输出效率