原文地址：http://www.51testing.com/html/78/23978-143163.html
1.测试概要
1.1 关于
这篇文档中涉及的基于JMS的消息系统能为应用程序提供可靠的，高性能的，异步的通讯机制。在不同的JMS解决方案中，性能是关键因素，但不是唯一的因素。每个方案都有不可比拟的属性和特性，还要考虑诸如实现难易、有效性、获得支持的性价比，等等。另外，标准的性能测试只能近似模拟各个企业的特定需求下的真实环境。
1.2 测试人员和工作量
测试人：nb_bull
工作量：50小时
1.3 测试方案
基于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在一段时间没有消息发送时抛出 "Channel was inactive for too long"异常。
消息内容：
<?xml version="1.0" encoding="UTF-8" ?><message><messageVersion>2</messageVersion><transactionId>17584926994300501924</transactionId><feeCode>2HSKYYXC</feeCode><spcode>11</spcode><phoneNum>13886344486</phoneNum><hsMan>rebound</hsMan><hsType>f420</hsType><vmVer>1940</vmVer><hsVer>101935</hsVer><imei>135790246811220</imei><imsi>460005804931145</imsi><appId>400001</appId><appVer>-1</appVer><feetype>0</feetype><provider>1</provider><reserve>0</reserve><moTime>20090708175847</moTime><cost>2.0</cost><chargeVer>0</chargeVer><application>0</application><module>0</module><appcontext>ABcWEwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==</appcontext></message>
消息大小646字节，会被消息产生者重复使用。
1.5.4 ActiveMQ相关
部署的ActiveMQ版本为现网部署的5.1.0版本。
采用AMQ Message Store的ActiveMQ缺省持久化存储方式，所有方案持久化使能persistent=”true”,日志等级设置为INFO。持久化时配置增大ActiveMQ缓存大小，<policyEntry queue=">" memoryLimit="100mb"/><policyEntry topic=">" memoryLimit="100mb"/>。
1.5.5.测试方案
方案一：在测试PC1上使用测试脚本往ActiveMQ集群以non-persistent方式异步发布JMS消息，在测试PC2上采用jmeter非持续订阅（non-durable Subscrition）方式接收消息。
方案二：在测试PC1上使用测试脚本往ActiveMQ集群以persistent方式异步发布JMS消息，在测试PC2上采用jmeter非持续订阅（non-durable Subscrition）方式接收消息。
方案三：在测试PC1上使用测试脚本往ActiveMQ集群以persistent方式异步发布JMS消息，在测试PC2上采用开发人员提供的监听模块持续订阅（durable Subscrition）方式接收消息。
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
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 部署建议
1．Increase the memory limit of the broker in activemq.xml，在实际上线时需要评估消息发布、接送之间的msg流量差，增大memory limit，如512MB或更大,同时需要注意配置分配给ActiveMQ的JVM内存是大于该配置容量。
2.建议以后对持续订阅模块进行性能评估后再上线部署，以防止消息订阅者性能低下而在ActiveMQ上造成数据堵塞；并保证持续订阅者的稳定性，避免出现长时间掉线的情况，测试证明消息堵塞对MQ性能的影响是很严重的。也可以通过配置消息生存时间、配置自动清除缓存等方式解决该隐患。
3.如果使用数据库模式的话建议使用c3p0的数据源。
4.使用non-persistent 方式速度较快，对于偶尔丢失少量数据不敏感的应用极为适合。
至此，该阶段的集群性能评估已经可以告一段落，完整诊断以后系统性能的瓶颈主要是在持续订阅模块上。而采用c3po数据源后的JDBC Master Slave性能与Shared File System Master Slave 性能比较接近。Pure Master Slave的问题在apache网站上搜索据说该BUG已在ActiveMQ5.2后fixed,不过鉴于该集群方案的稳定性和以及故障后本身固有的处理缺陷暂不采用。
顺便提及jmeter在测试JMS中碰到的几个问题：
1.Jmeter默认的传送方式是同步:在集群时可以在jndi中采用failover:(tcp://172.16.11.241:61616,tcp://172.16.11.242:61616)?jms.useAsyncSend=true这样的方式修改为异步方式。
2.jmeter默认采用非持久（non-persist)发布：这个貌似在发布/订阅模式下无法修改，很奇怪在队列模式下是有该切换选项的。
3.jmeter默认采用非持续（non-duration)订阅：这个也貌似无法修改。
4.jmeter的订阅模块有一个BUG：要使用listen方法监听系统必须先切换到receive方式再切换回来才能生效。
可见jmeter对JMS测试的支持仍然是不够完善的，如果要全面的测试JMS各种发布订阅模型，还是不得不采用手写测试脚本的方法去完成。