On Wed, Jul 28, 2010 at 12:34 PM, Gordon Sim <[email protected]> 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. > 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. > 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? --Brian --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
