On 07/28/2010 06:55 PM, Brian Crowell wrote:
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.
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:[email protected]
