23
生產性能我創建了一個簡單的生產者消費者模擬基於Spring，JMS和ActiveMQ的， 我試圖達到雙方，生產者和消費者高性能，JMS彈簧
連接設置：
<tx:annotation-driven />
<bean id="transactionManager" class="org.springframework.jms.connection.JmsTransactionManager">
<property name="connectionFactory" ref="connectionFactory" />
</bean>
<amq:connectionFactory id="amqConnectionFactory" brokerURL="failover:(tcp://${broker.url}:61616)" />
<bean id="connectionFactory"
class="org.springframework.jms.connection.CachingConnectionFactory">
<property name="targetConnectionFactory" ref="amqConnectionFactory" />
</bean>
<amq:queue id="queue" physicalName="queue" />
<beans:bean id="jsonMessageConverter" class="XXXXX.converter.JsonMessageConverter" />
消費者設置：
<jms:listener-container concurrency="10"
acknowledge="auto" prefetch="1" message-converter="jsonMessageConverter" transaction-manager="transactionManager"
>
<jms:listener id="queueListener_1" destination="ooIntegrationQueue"
ref="myMessageListenerAdapter" />
</jms:listener-container>
<beans:bean id="myMessageListenerAdapter"
class="org.springframework.jms.listener.adapter.MessageListenerAdapter" >
<beans:property name="delegate" ref="consumer"/>
</beans:bean>
<beans:bean id="consumer" class="XXX.ConsumerImpl"/>
監製設置：
<beans:bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate"
p:connectionFactory-ref="connectionFactory" p:messageConverter-ref="jsonMessageConverter"
p:defaultDestination-ref="ooIntegrationQueue" p:sessionTransacted="true" />
開始與消費者，我設法消耗大約每秒25的消息，這是非常慢的，我發現了這個瓶頸是我使用的交易， google搜索了一下後，並用打的事實CONFIGS，我發現，同時還具有自動裝配的交易中使用DefaultMessageListenerContainer和改變cachelevel後
listenerContainer.setCacheLevelName("CACHE_SESSION")
我的性能提升到每秒約1500的消息。
我現在的問題是它仍然停留在每秒約25行動生產者， 我的製片測試很簡單：
int numOfMessages = getNumberOfMessages();
double startTime = System.currentTimeMillis();
for (int i = 1; i <= numOfMessages; i++) {
jmsTemplate.convertAndSend("HelloWorld" + i);
}
double endTime = System.currentTimeMillis();
double totalTime=(endTime-startTime)/1000;
System.out.println("Time - "+totalTime+" seconds");
System.out.println("EPS - "+numOfMessages/totalTime);
我不知道如何與製片達到similiar演出，因爲它現在已經成爲整個系統的瓶頸。
當前好消息是不持久的，我調試jmsTemplate和會話和生產者緩存，我決定嘗試一個沒有春天的基本示例，並且事實證明（這是有道理的）提交每個消息的會話結果都是相同的性能，只有一定數量的消息被填充，然後提交事務才能獲得理想的結果。 – Matan
如果普通香草測試和基於彈簧的測試具有相同的性能，那麼您可以非常確定該代理的瓶頸。 25/s等於每條消息40ms。這可能是非常合理的，取決於代理人的方式（以及發送是否是異步的）以及取決於它如何處理消息以及它運行什麼硬件。什麼是默認傳送模式？我的猜測是'PERSISTENT'，如果是這樣，嘗試切換到'NON_PERSISTENT'，你應該看到吞吐量增加。如果還沒有默認發送，你還應該考慮使用異步發送。 – Matt