On 06/14/2013 07:22 PM, Connor Poske wrote:
I have a tangential question(s) regarding performance under load.
If one wanted to "scale out" a client receiver so as to achieve the
maximum possible throughput on a multi-cored machine, would it be
optimum to go with 1 thread per Session? Another way of asking would
be this: Between Connections, Sessions, and Receivers, which should
you scale horizontally in a multi threaded fashion in order to
achieve optimum performance?
I would start by scaling out connections, with one session per
connection, one receiver per session. At the network io level everything
is serialised for the connection, and there is no real parallelism on
the broker between sessions or receivers on the same connection anyway.
Obviously once you get beyond a certain number of connections this
becomes less of an issue on the broker, since the connections are all
competing for CPU time anyway.
Has anyone done any load testing to
determine what the optimum configuration is?
It may make sense to consider end-to-end optimum configurations also.
The question could also be: If you really wanted to get as much data
as possible per second from Sender A through Broker B to Receiver C,
maximizing multi-cored hardware, what would that look like? Does
having multiple Senders, Receivers, Sessions, Connections set up in a
multi-threaded way even yield a benefit over just stuffing everything
through one pipe? Should we define queues per Sender/Receiver thread
pair at the broker or does that not make a difference in
performance?
Separate queues will generally improve throughput (less contention).
However pulling with two receivers from the one queue will generally
increase the throughput over a single receiver (though it won't double
it), so there can be benefit from exploiting extra processing power on
the client.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
