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

Question

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

JMSTemplate.receive(queueName);

将这段代码封装在一个简单的计时器中后，我发现接收花费的时间为 20-50 毫秒，并且由于我正在处理的吞吐量绝对会随着时间的推移而增加。经过一番谷歌搜索后，我偶然发现了 Spring“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 Queue Manager 的连接

2)打开指定队列

3)从队列中获取消息

4)关闭队列

5) 关闭连接。

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