activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <mattr...@gmail.com>
Subject Re: Consumer performance problem with Tx
Date Mon, 08 Sep 2014 16:33:36 GMT
Justin-

JMS connections act and behave very different from JDBC connections.  Just like a long query
can block other apps trying to access the connection on a shared JDBC connection, a slow consumer
can impact others trying to access it as well. You can do multiple sessions on top of a single
connection, but it can get hairy and I don’t get the sense that the intention was to support
connection pooling, but rather allow for a single program to do all its producing and consuming
over a single connection— not several programs sharing a single connection.

Separate connections per consumer is always a safe starting point. Pre-tuning for shared JMS
connections, usually results in de-tuning. I think you’ll find single connection per consumer
will meet your performance needs.  

If you absolutely feel like you must share sessions on top of a single connection, reduce
prefetch=“1”, ensure your memoryLimit is well above the default “1 mb”, use NIO on
the transportConnector, optimizedDispatch=“true” and dedicatedTaskRunner=“false”.

-Matt

On Sep 8, 2014, at 6:25 AM, James Black <be_strew@yahoo.co.uk> wrote:

> Hi Matt,
> 
> we don't use JmsTemplate in this particular bit of code.
> 
> I have done some testing this morning and the problem seems to be contention
> with the shared connection.  The Spring DMLC is configured to cache at
> Connection, Session and Consumer level.  If caching is enabled at all
> (connection+) then it uses a shared single connection.  I can verify this by
> monitoring ActiveMq through Jmx.
> 
> So if I have a DMLC with 20 consumer threads, all sharing the same
> connection it is slow, but at low throughput you would not notice.
> 
> If I create 20 separate DMLCs all with a single thread and all with
> different connections, then the performance is great in comparison!
> 
> Not sure why this would be as I believed that it is normal to share the
> connection for JMS unlike JDBC and I would of assumed that ActiveMQ is
> optimised for that case?
> 
> Thanks,
> 
> Justin
> 
> 
> 
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/Consumer-performance-problem-with-Tx-tp4685226p4685365.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message