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? 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? I hope this makes sense! Thanks, Connor ________________________________________ From: Gordon Sim [[email protected]] Sent: Friday, June 14, 2013 1:35 AM To: [email protected] Subject: Re: Is the class Receiver in QPID thread safe On 06/14/2013 12:41 AM, Rajesh Khan wrote: > While going through some QPID code I wanted to know if the Receiver Class > in QPID is thread safe (i.e) Any drawbacks if multiple threads access it at > the same time ? It is intended to be threadsafe. Occasionally of course there are bugs, e.g. https://issues.apache.org/jira/browse/QPID-4786 or https://issues.apache.org/jira/browse/QPID-4764. However, I'm not convinced there is generally a great deal of benefit in having multiple threads fetching from the same receiver (or indeed the same session). I myself would probably aim for a design that had a thread per session, unless there was a clear reason not to. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
