I did a fair bit of performance tuning for the basic system before I committed it all initially. This was mostly along the lines of the single producer/consumer latency you are talking about, no real testing with lots of queues.
A few things have been added again since then, so there might be areas where improvements can be made, and of course you might find some things I missed. good luck David > -----Original Message----- > From: Loren Rosen [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 16, 2001 11:28 AM > To: Hiram Chirino; [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] jbossmq: persistence implementation questions > > > > > Hiram Chirino wrote: > > > Hi Loren! > > > > >From: Loren Rosen <[EMAIL PROTECTED]> > > >To: "[EMAIL PROTECTED]" > > ><[EMAIL PROTECTED]> > > >Subject: [JBoss-dev] jbossmq: persistance implementation questions > > >Date: Mon, 12 Nov 2001 20:22:27 -0800 > > > > > > > > > >* Performance tuning/scalability: has any work been done to address > > >potential bottlenecks for high message throughput, large numbers of > > >queues or topics, etc.? > > > > > > > Work has gone into making reading/writing from storage more > efficient. I > > don't think we have profiled the system enough yet to find > out where the > > bottle necks are. > > A good first step would be to measure the single > producer/consumer latency, > and tune that. Low latency is a important goal in its own > right, and moreover > if the CPU overhead is too high you won't even be able to > keep the disk > busy writing messages. I can go ahead and do this. > > > > > > > >* recovery robustness: recovery is a tricky thing since > there's so many > > >possible ways things can fail. What's been done to think > > >about/test-for/defend-against all the possibilities? > > > > > > > Basic recovery test have been succeeding. It's hard to > automate failure > > testing. More code review would be good in this area to > see if we are > > missing anything. > > I'll look through the code more closely. But recovery is > testable. What > you have to do is create some corrupt data files (probably by using a > byte-level editor to munge some existing data files). Then you need > some scripts to start up the server with those files -- which doesn't > fit so well with a pure-Java Junit-based test suite. (You could also > create the files by making versions of the server which quit at > various awkward places.) What this won't test so easily is recovery > from failures during recovery. > > > Regards, > > Hiram > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
