qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: QPID message throughput - Red Hat numbers
Date Wed, 28 Jul 2010 19:01:35 GMT
On 07/28/2010 06:55 PM, Brian Crowell wrote:
> On Wed, Jul 28, 2010 at 12:34 PM, Gordon Sim<gsim@redhat.com>  wrote:
>> What are your settings for the subscriber? Try batching (or not requiring)
>> acks. I wouldn't expect a single producer to be overwhelmingly faster than a
>> subscriber.
> I'm using the Qpid C++ client API. My accept mode is explicit (so I
> don't receive more messages than I can process; this isn't really much
> of a problem anymore, as I've hit Qpid's limit now). Messages are
> pre-acquired, there's a window of 1000 messages, and autoAck is 5. I'm
> using the SubscriptionManager with a callback.
> With these settings, my receive rate comes pretty close to what I can
> get with perftest. I'm experimenting with scheduling priorities and
> CPU affinities to see what kind of improvements I can get.

11k is very slow, if you can get a linux box with more cores I would 
expect that to go up significantly.

>> So the subscriber isn't actually interested in all the messages coming in?
>> Again that should make a difference as the subscriber rate doesn't need to
>> match the total publisher rate.
> This *particular* subscriber is interested in 99.9% of what the
> publishers push. Other subscribers will bind to specific topics.

Ok, so the rate for that subscriber will be the limiting factor in the 
overall system. Is there any opportunity at all for somehow splitting 
that subscribers job up?

>> Sessions won't really improve things; the unit of parallelism on the broker
>> is at the connection level. Each connection is processed by a single
>> thread/core at a time.
> Interesting, I thought I had read the opposite somewhere. So sessions
> are mainly for picking up where you left off?

Sessions are for multiplexing different logical streams over a single 
connection. On the *client* you can have different sessions processed by 
different threads which can give you some parallelism, but on the server 
its at the connection level only.

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message