Henry Robinson wrote:
Hi -I'm getting disappointing performance reading from a Qpid queue into a simple Mule endpoint (that does essentially nothing) - about 150 msgs/s. I'd appreciate some guidance about performance tuning. This is all running on the same machine - an 8 core Xeon machine with 8Gb of RAM. Here's the relevant JMS configuration in Mule: <jms:connector name="JMSConnector" connectionFactory-ref="qpidfactory" specification="1.1" persistentDelivery="false" numberOfConsumers="10" maxRedelivery="2"> <receiver-threading-profile doThreading="true" maxThreadsActive="10" maxThreadsIdle="5" threadTTL="60000"/> <dispatcher-threading-profile doThreading="true" maxThreadsActive="10" maxThreadsIdle="5" threadTTL="60000"/> </jms:connector> If I jstack the mule process (unscientific, to be sure, but attaching a profiler causes the whole thing to die slowly under timeouts) I notice that the Dispatcher threads are almost all blocked on AMQConnection.createSession (which has a single-occupant critical section). So should I have enabled something that allows for session reuse? Alternatively, are there some other performance tweaks I can attempt? (I have looked here: http://qpid.apache.org/how-to-tune-m3-java-broker-performance.html already). Sorry if this is actually a Mule question, but as you can see the issue appears to be in Qpid code. Thanks in advance for your advice. cheers, Henry
I run the C++ broker, so can't directly comment on the above but it might be worth a spin with both brokers as that will tell us if it is broker setup or something with the client integration with mule. For C++ broker for your box I
would guess 25-30k small transient messages per second from the Java client. Carl. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
