H.E.'s Blog

Story1
现象
项目需要采用JMS 消息中间件OpenMQ 来发送、接收一对多消息。前期需要进行对性能进行模拟测试，开始测试时发送端没有问题循环1000次发送Topic消息顺利结束，但是Topic接收端表现异常，间隔50个一次的接收消息进行处理，如果把1000个消息处理完成大概需要30分钟，更别说下面还要启用100个线程发送1000次了。

环境
3台JMS 消息中间件OpenMQ集群，Linux
1台消息发送端，Windows
1台消息接收端,  Windows
如图所示：
 

查看大图请点击这里

代码
发送端代码 (下载url) 
接收端代码 (下载url)

需要的Jar包

经过几番测试，猜测问题多数是由于接收端与服务器端连接的配置而导致的，仔细检查发现多写了几行代码，接收端验证的部分，也就是说对于JMS的消息收发加上验证是对效率有影响的，去掉用户名、密码验证一切正常。

Story2
100个线程同时发送100个消息，一共10w个消息，运行到一半的时候出现
[29/Mar/2010:03:34:07 EDT] [B1089]: In low memory condition, Broker is attempting to free up resources
[29/Mar/2010:03:34:07 EDT] [B1088]: Entering Memory State YELLOW from previous state GREEN  – allocated memory is 151214K, 80% of total memory used
显然在说内存不够。经过google以后证明我的想法是正确的，参考文档：
http://docs.sun.com/app/docs/doc/819-4467/6n6k98bq2?l=zh_tw&a=view#aeokn
http://docs.sun.com/app/docs/doc/819-4467/6n6k98bqa?l=zh_tw&a=view
加大运行内存，命令如下：
nohup imqbrokerd -tty -name myBroker -port 6769 -cluster 172.16.2.214:6769,172.16.2.215:6769 -D"imq.cluster.masterbroker=172.16.2.215:6769" -vmargs "-Xms256m -Xmx1024m" &

话外音
1.可以用imqcmd metrics bkr -m cxn -b 127.0.0.1:6769命令查看JVM空闲值，最大值，最小值和当前OpenMQ的运行状态。
2.对于消息发送时还需要注意客户端的消息确认模式一共有3种客户机确认模式，根据需要的不同级别的处理和带宽开销进行选择：
          AUTO_ACKNOWLEDGE 模式的开销最大，可以保证消息逐条传送的可靠性；
          CLIENT_ACKNOWLEDGE 模式按批次发送确认，因此需要的带宽开销较小；
          DUPS_OK_ACKNOWLEDGE 模式的开销最小，但允许重复传送消息。

相关文章：
Glassfish(EJB) 与Quartz Job Scheduler整合
GlassFish 性能优化
GlassFish JMS 集群
GlassFish 文档
GlassFish 数据库连接池的配置步骤(图解)

–end–