精品文档 你我共享
1.测试概要 1.1 关于
这篇文档中涉及的基于JMS的消息系统能为应用程序提供可靠的，高性能的，异步的通讯机制。在不同的JMS解决方案中，性能是关键因素，但不是唯一的因素。每个方案都有不可比拟的属性和特性，还要考虑诸如实现难易、有效性、获得支持的性价比，等等。另外，标准的性能测试只能近似模拟各个企业的特定需求下的真实环境。 1.2 测试方案
基于JMS的消息传递分为两方面，基于队列的点对点模式和对于主题的发布-订阅模式，这次主要针对Topic方式执行测试。
测试中每个发送者和接收者所发送和接收的消息数目都将被记录。数值采样将会从测试系统初始化完成时开始，并在规定的时间段内持续进行，于系统开始关闭前结束.
1.4 测试环境与配置
所有的测试都在两台服务器（主从）上完成，消息消费者和提供者被安装在x86的机器上，配置为2.40G CPU和1.0GB内存，操作系统为Windows XP，所有机器在同一个网段的局域网内相连。 1.5 测试场景 1.5.1 集群类型
本次性能测试主要测试比较几种Master-Slave集群配置方案和默认配置，我们对每个JMS项目采用默认的out-of-the-box配置。 a.Pure Master Slave
b.Shared File System Master Slave
c.JDBC Master Slave（DB only）（采用默认数据源） d.JDBC Master Slave(File&DB）（采用c3P0数据源） e.单点非集群模式 1.5.2 测试场景
单个提供者，单个用户，和单个主题或队列（1 producer, 1 subscriber, and 1 topic）
1.5.3 消息配置
java.naming.provider.url：
tcp://localhost:61616?jms.useAsyncSend=true&wireFormat.maxInactivityDuration=0
消 息发布时采用异步发送流（useAsyncSend）模式，加入
wireFormat.maxInactivityDuration=0 这样的参数，避免ActiveMQ在一段时间没有消息发送时抛出 \异常。 消息内容：
encoding=\ctionId>17584926994300501924 AAAAAA 精品文档 你我共享 eserve>0 消息大小646字节，会被消息产生者重复使用。 1.5.4 ActiveMQ相关 部署的ActiveMQ版本为现网部署的5.1.0版本。 采 用AMQ Message Store的ActiveMQ缺省持久化存储方式，所有方案持久化使能persistent=”true”,日志等级设置为INFO。持久化时配置增大 ActiveMQ缓存大小， 2测试结果及缺陷分析 2.1 测试执行情况与记录 2.1.1方案一 Publish: non-persistent, useAsyncSend Subscrition:non-duration(jmeter listen) 主题模式：1 producer, 1 subscriber, and 1 topic ActiveMQ集群方案 每秒消息数(msg/sec) Pure Master Slave 7541 Shared File System Master Slave 7760 JDBC Master Slave（DB only） 7260 JDBC Master Slave（File&DB） 7681 单点非集群模式 8226 数字代表在每个测试时间间隔中每秒发送的消息数。数值越高代表性能越好。 测试中发布的消息被jmeter迅速接收处理，各种部署方式数据处理性能接近。 2.1.2方案二 Publish: persistent, useAsyncSend Subscrition:non-duration（jmeter listen） 主题模式：1 producer, 1 subscriber, and 1 topic ActiveMQ集群方案 每秒消息数(msg/sec) Pure Master Slave 6663 Shared File System Master Slave 7189 JDBC Master Slave（DB only） 7002 AAAAAA 精品文档 你我共享 JDBC Master Slave(File&DB） 7052 单点非集群模式 7471 数字代表在每个测试时间间隔中每秒发送的消息数。数值越高代表性能越好。 测试中发布的消息被jmeter迅速接收处理，各种部署方式数据处理性能接近。 2.1.2方案三 Publish: persistent, useAsyncSend Subscrition:duration(采用开发人员提供的subscription模块) 主题模式：1 producer, 1 subscriber, and 1 topic ActiveMQ集群方案 每秒消息数(msg/sec) Pure Master Slave \\ Shared File System Master Slave 25 JDBC Master Slave（DB only）默认数据源 3 JDBC Master Slave(File&DB）采用c3P0数据源 22 单点非集群模式 55 该方案采用开发人员提供的订阅模块进行对集群进行持续订阅，测试中可以发现： 1.由于该订阅模块的处理能力较差，导致大量发送数据的堆积拥塞，每秒的处理消息能力糟糕。 2.JDBC模式使用c3P0数据源后，运行效率更加稳定和高效。 3.Pure Master Slave在此测试场景下，由于数据的大量拥塞迅速失去响应。 3测试结论与建议 3.1 测试结论 1.Pure Master Slaver集群方式重新启动MQ服务后原来连着的用户发送订阅消息，MQ会一直提示”Cannot lookup a connection that had not been registered”（ActiveMQ5.1）。 2. JDBC Master Slave（DB only）集群方式使用默认数据源进行测试时，频繁写入数据库， 导致性能低下，MQ日志开始频繁报出“ERROR StoreDurableSubscriberCursor - Failed to get current cursor”的错误信息，JDBC Master Slave(File&DB）集群方式，使用默认数据源进行测试时，系统日志频 繁报出“ERROR JournalPersistenceAdapter –Failed to checkpoint a message store: java.util.concurrent.ExecutionException: java.io.IOException: Already started. ”（更换了c3P0数据源后该问题可解决）。 3.Shared File System Master Slave在本次采用activeMQ5.1进行集群测试的时候也发现了一个BUG，在集群运行一段时候后会出现slave MQ的crash，日志显示为“java.io.FileNotFoundException: **/*****/***/******/journal/control.dat (Too many open files)”，在ActiveMQ的网站上找到了该BUG的错误报告。可通过升级到ACtiveMQ5.3或下载一个补丁jar包放到lib的方式来解决。 3.目前开发提供的数据订阅模块在可持续订阅（duration）时处理效率较差，后续需要进行优化。 3.2 部署建议 AAAAAA