Spring JMSTemplate with ibm.mq.jms.MQQueueConnectionFactory

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 Queue Manager的連接

2）打開指定的隊列

3）從隊列中獲取消息

4）關閉隊列

5）關閉連接。

由於上述所有操作，接收單個消息所花費的時間更多。 但是當緩存會話時，Spring會重新使用緩存連接。 因此更好的消息接收吞吐量