带有 ibm.mq.jms.MQQueueConnectionFactory 的 Spring JMSTemplate

Question

我正在开发一个发送/接收数十万条消息的 JMS 密集型应用程序。我发现性能并不是那么好，并将问题缩小到如下所示的 1 行，据我所知，根本原因是它不能很好地与 IBM MQ 配合使用。

JMSTemplate.receive(queueName);

将此代码包装在一个简单的计时器中后，我发现接收需要 20-50 毫秒，并且由于我正在处理的大量吞吐量，随着时间的推移，它肯定会加起来。经过一番谷歌搜索后，我偶然发现了弹簧“CachingConnectionFactory”，我用下面的运气实现了它（不确定这是否适用于我已经在使用的 IBM MQ Connection 工厂）。请注意，为了便于阅读，省略了一些代码...

    <bean id="jmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
        ...
    </bean>

    <bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
        <property name="connectionFactory">
            <ref bean="cacheFactory" />
        </property>
        ...
    </bean>

    <!--This seems to be the magic piece-->
    <bean id="cacheFactory"
        class="org.springframework.jms.connection.CachingConnectionFactory">
        <property name="targetConnectionFactory" ref="ibmMQConnectionFactory" />
        <property name="sessionCacheSize" value="100" />
    </bean>

    <bean id="ibmMQConnectionFactory" class="com.ibm.mq.jms.MQQueueConnectionFactory">
        ...
    </bean>

令我惊讶的是，这将我的 JMSTemplate.receive() 调用从 20-50+ 毫秒之间的任何时间减少到每条消息大约 1-2 毫秒。我无法找到任何关于这在幕后如何运作以及“sessionCacheSize”将如何影响性能的可靠信息。我的第一次测试我使用了 50 的值，第二次使用了 100，第二个选项证明更快。所以我的问题是，对于具有大量吞吐量的应用程序来说，理想的“sessionCacheSize”是什么？这种方法有哪些缺点需要考虑？

我期待你们对这个问题的看法......

Answer 1

我对 Spring 的了解有限。但是通过阅读您的描述，我相信 Spring 每次接收消息时都会执行以下操作：

1) 创建与 IBM MQ 队列管理器的连接

2) 打开指定队列

3) 从队列中获取消息

4) 关闭队列

5) 关闭连接。

由于以上所有操作，接收单个消息所花费的时间更多。但是当 session 被缓存时，Spring 正在重新使用缓存的连接。因此更好的消息接收吞吐量。