Hi Jason, On 26 March 2013 13:26, Jason Barto <[email protected]> wrote:
> Rob, > thanks for your quick response - I've consolidated the code into a single > java file and would gladly publish it - frankly being new to AMQP 1.0 and > its client libraries I'd value the feedback. I think I may have determined > the reason for the slow down - not sure why it didn't occur to me earlier > to be honest. > > I have 2 threads, a Sender and Receiver. Both are trying to produce / > consume as rapidly as possible. Testing on my laptop the Sender is > publishing on average 20k messages / sec while the receiver seems to top > out at 15K msg/sec, leading to an inevitable backlog of messages building > up on the broker. When the queue on the broker is holding around 500k > messages (after about 90 seconds of testing) the performance of the broker > drops dramatically until both producer / consumer can only send / receive > about 200 msg/s. > > OK - great (sort of) - we can understand the problem - basically the broker is not sufficiently pushing back on the producing client when the queue becomes over full. The broker can be used to enforce flow control when using earlier versions of the protocol (0-8, 0-9, 0-9-1, 0-10) but it's entirely possible that this is not yet implemented in the 1-0 codepath (I shall have to go check... if it is not I'll attempt to implement it shortly). In general the broker performance shouldn't degrade until it starts running out of memory, whereupon the garbage collector will start dominating the performance. > If I put a limit on the number of messages / sec sent by the producer the > problem goes away, ie the receiver can consume the messages at a rate to > prevent a backlog of messages. I'd be happy to create a JIRA request if > you feel one is necessary; is there perhaps a datastore I could configure > QPid to use that would help the system to better deal with the growing > backlog mentioned? I ask as a mitigation technique. I'll be becoming a > sysadmin for an enterprise-level message broker that will be expected to > handle 1.75B messages per day (roughly 20k/s). If for some reason the > messages are not being consumed at the same rate they're being produced - > what options do I have to ensure that QPid's performance is unaffected? > > I guess the question is how large do you want to let the queue grow before you have to enforce some sort of restriction on the sender? Adding flow-to-disk style capabilities often just makes the problem worse because the consumer starts to become limited by the speed at which messages can be read from disk, which may be lower than it's optimal rate... so you start seeing even more queue growth. I've seen people who want to be able to handle spikes in queue growth of up to several million messages... and the answer to their problem was just to stuff a lot more RAM into their machine :) As an aside are you expecting these 20K/s messages to be AMQP 1.0? As I mentioned in my last mail, I've not yet done *any* perf tuning on the AMQP1.0 code (JMS client or broker)... Though your question yesterday has forced me to dig up my old copy of JProfiler and run it on the broker for the first time today :-) Cheers, Rob > Sincerely, > Jason > > > On Mon, Mar 25, 2013 at 7:08 PM, Rob Godfrey <[email protected] > >wrote: > > > Hi Jason, > > > > the AMQP 1-0 support in the java broker is somewhat experimental at > > this stage (and no perf tuning has been carried out), however it > > definitely seems like you've found a bug. Can you share some more > > details of your test (perhaps raise a JIRA and attach the test code?) > > and I'll try to look into it ASAP - hopefully that way we can get a > > fix in for 0.22, > > > > Thanks, > > Rob > > > > On 25 March 2013 19:20, Jason Barto <[email protected]> wrote: > > > Using amqp 0.9.1 I'm getting an average performance of 70k messages per > > > second throughput during an hour long test. > > > > > > When using amqp 1.0 I receive similar but smaller throughput numbers > > > however after about 90 seconds of testing this quickly begins to drop > > until > > > it gets to 10s or 100s of messages per second and a significant backlog > > of > > > messages begins building. > > > > > > Can anyone explain this drastic difference in performance? I am using > > v0.20 > > > of qpid-j for the brokering. > > > > > > Sincerely, > > > Jason > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
