[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-users
Subject:    RE: Replye-Request pattern performance
From:       "Andres Rangel" <andresr () corp ! moniker ! com>
Date:       2010-01-28 15:36:31
Message-ID: 886461EE661A1E45BAA97AF28FAA85DB025742D6 () barbados ! corp ! oversee ! net
[Download RAW message or body]

Jose thanks for replying.

>> There is overhead when creating/destroying the queues,
In our case, this overhead is negligible, since we are using pools (the
temp queues are created once in the lifetime of the connection)

>> and in terms of memory usage there is the default stack size
allocated 
>> for each thread

We don't have a memory issue.

The performance I am referring to is speed. I would like to know if by
using one shared connection on the receiving end and dispatching the
messages using the correlation id is faster" than having each client
with it's own temporary queue.




-----Original Message-----
From: Jose Luna [mailto:j-luna@rocketmail.com] 
Sent: Wednesday, July 22, 2009 1:36 AM
To: users@activemq.apache.org
Subject: Re: Replye-Request pattern performance


> We have a pool of generic clients that each is listening to it's own
> temporary queue and all write to a common queue. These connections are
> open at creation time. They remain open until they get evicted by the
> pool manager.
> 
> We have different applications that use this pool, and the size of the
> pool is between 200-500 ,so  we may have 2500 clients connected (each
> one with it's own temporary queue).
> 
> My question is: What is the performance penalty of using temporary
> queues? 
> 
> Should I consider using one single queue for the receiving of the
> messages, and dispatch it using correlation Id?
> 
> Will this improve the performance on my system?
 
There is definitely a performance penalty for using temporary queues.
There is overhead when creating/destroying the queues, and in terms of
memory usage there is the default stack size allocated for each thread.
If recommend reading
http://www.nabble.com/Large-number-of-queues-(HowTo)-to23602928.html for
some info on how to improve performance with a large number of queues.

JLuna


> We have our own implementation of a request-reply message.



      

[prev in list] [next in list] [prev in thread] [next in thread]