I was just considering wasting a bunch of time (building test frameworks) to figure out an answer to this same question - I'm hoping someone has a good answer!
On Fri, Jun 14, 2013 at 1:22 PM, Connor Poske < [email protected]> 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? 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] > >
