内容发布更新时间 : 2024/9/21 15:46:32星期一 下面是文章的全部内容请认真阅读。

ActiveMQ 与 JORAM的比较

ActiveMQ特性：

? 多种语言和协议编写客户端。语言: Java, C, C++, C#, Ruby, Perl, Python, PHP。应用

协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP ? 完全支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务)

? 对Spring的支持,ActiveMQ可以很容易内嵌到使用Spring的系统里面去,而且也支持Sp

ring2.0的特性

? 通过了常见J2EE服务器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的测试,其中通过J

CA 1.5 resource adaptors的配置,可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上

? 支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA ? 支持通过JDBC和journal提供高速的消息持久化 ? 从设计上保证了高性能的集群,客户端-服务器,点对点 ? 支持Ajax

? 可以很容易得调用内嵌JMS provider,进行测试 ? ActiveMQ里面通过JAAS实现安全机制。

ActiveMQ缺点：

? ActiveMQ默认的配置性能偏低，需要优化配置，但是配置文件比较复杂，activemq本

身不提供管理工具；示例代码比较少。

? 开发文档看上去比较全面，但是缺乏一种有效的组织方式，文档只有片段，用户很难由

浅入深进行了解，二来文档整体的专业性太强，在研究阶段可以通过查maillist、看Javadoc、分析源代码来了解。

JORAM的优点：

? 文档非常完备，并且带有很多示例，就算没有JMS任何经验的人一遍看下来，也能完

成对JORAM的配置和管理

? 自带管理工具，配置JNDI非常方便，也可用于对生产系统进行分析管理，找出潜在的

问题所在

? 支持JMX，可以通过JMX工具进行管理 ? 方便简单的权限控制

JORAM的缺点：

? 判断JMS客户端是否在线非常缓慢，有时甚至不会通知应用。调用consumer.receive()

后，即使网络连接断开，该方法也不返回，也不抛出异常，就这样一直傻等的情况。所以不得不把底层的JMS连接框架换成consumer.receive(long timeout)，这样等到下一次接收时抛出异常时，会尝试自动重连。对于duration的连接就更麻烦了，碰到过网络连接断开后重连就抛The durable subscription XXXX has already been activated 异常，而这个异常只有在JMS服务器重启后才能得到解决。

? 持久化机制有问题。JORAM采用的是Java序列化的方式来持久，可是它的序列化类里

面居然连serialVersionUID都没有定义！这意味着什么？即使知道4.3.8比4.3.1有了改进，可是我们也无法部署到生产系统上，因为无法把持久化的消息给读出来！这点令我非常郁闷，这意味着基本上只能绑定在生产系统上的这个版本。

? 开发社区没有开放Bug管理系统，碰到问题也很难反馈，虽然可以通过maillist反馈一

些信息，但是毕竟非常不方便。

ActiveMQ 基准性能测试

所有的测试都在两台服务器上完成。服务器由网线相连。消息消费者和提供者被安装在x86的机器上，配置为2.40G CPU和1.0GB内存，操作系统为Windows Server 2003 SP1，Broker被安装在一台x86机器上，配置为2.40G CPU和1.0GB内存，操作系统为Windows Server 2003 SP1。

测试安装

整个测试使用自定义的JMS性能测试模块，兼容JMS1.1.没使用特定的代码。加载插件类用于JMS连接。

下面的JMS设置用于所有测试用例 - 非事务会话

- 自动通知模式会话

- 使用onMessage()方法异步接收消息 - 持续订阅会在完成接收动作后被取消

- 如果测试用例中有超过1个目的地址，消息发送这会给每个目的地址发送消息。 - 消费者只能从一个目的地址中消费消息 - 消息大小为1Kb，会被消息产生者重复使用 - 每个JMS连接只使用单个JMS客户端

测试中每个发送者和接收者所发送和接收的消息数目都将被记录。数值采样将会从测试系统

初始化完成时开始，并在规定的时间段内持续进行，于系统开始关闭前结束，请参考下面的采样过程示例：

总消息数：5

平均数：0.625 秒/采样间隔（5消息/8采样间隔） 默认每秒采样一次

Broker配置

我们对每个JSM项目采用默认的out-of-the-box配置，包括ActiveMQ。同时，我们将对ActiveMQ其他配置进行测试。

? ActiveMQ + Kaha persistence ? ActiveMQ (优化设置) Kaha persistence 异步发送为true

对主题和队列的Message prefetch分别设置为 65532 和 2000

ActiveMQ优化

本次性能测试将不但显示ActiveMQ相对于其他JMS项目的性能，同时还会显示对ActiveMQ调优后其性能的提升。在每个测试中，进行三种配置，保持默认配置、使用Kaha persistence机制、进行优化配置以获得高性能。

Kaha持久化机制是一种新的基于文件方式保持高性能消息传输的消息持久化机制，更多信息请参考：http://www.activemq.org/site/kaha-persistence.html。其他优化方式同样能提高ActiveMQ的性能。ActiveMQ第三种配置使用上述这些优化方式保证了ActiveMQ高性能传输。更多有关ActiveMQ性能优化请参考：

http://devzone.logicblaze.com/site/apache-activemq-performance-tuning-guide.html。

主题访问（Topic Destination）结果

该基准测试将使用4钟不同的组合，包括传输模式和订阅类型： 持久性 和 持续型（persistent and durable）

持久性 和 非持续型（persistent and non-durable） 非持久性 和 持续型（non-persistent and durable）

非持久性 和 非持续型（non-persistent and non-durable） 另外，每个测试将经历3个场景：

单个提供者，单个用户，和单个主题或队列（1 producer, 1 subscriber, and 1 topic） 十个提供者，十个用户，和单个主题或队列（10 producers, 10 subscribers, and 1 topic） 十个提供者，十个用户，和十个主题或队列（10 producers, 10 subscribers, and 10 topics）

主题模式：1 producer, 1 subscriber, and 1 topic