On 5 January 2012 22:56, Daryoush Mehrtash <[email protected]> wrote:
> > > > For persistent messaging the solutions have been tuned for very different > > use cases it seems, with the Java performing better when the clients are > > operating in a highly synchronous manner with high levels of concurrent > > connections. The C++ (on Linux) is obviously much better tuned for the > > asynchronous persistent messaging case where it can achieve throughputs > > much higher than the Java could aspire to due to the lack of an > > asynchronous IO API. > > > Would you please explain what you mean by "highly synchronous manner with > high levels of concurrent > connections" and "asynchronous persistent messaging". An example would > help. > For the synchronous case I mean something like: Producers and consumers using transactions for each send or receive. Multiple such connections running in parallel (particularly if each connection may be operating on a different queue). For the asynchronous case what I mean is that you are not waiting synchronously after you send/receive each message. In the producer case this means that there are some number of messages which it knows it sent but it doesn't know that the broker has persisted. On the consumer side it means that the client may delay acking messages, and/or does not wait to hear confirmation that the ack has been processed. The consequence being overall that there are more messages "in doubt" at any one time, however your overall throughput is much higher. Hope this helps, Rob > > Thanks > > Daryoush > > > On Thu, Jan 5, 2012 at 1:39 PM, Rob Godfrey <[email protected]> > wrote: > > > On 5 January 2012 20:39, William Henry <[email protected]> wrote: > > > > > Hi Rob, > > > > > > I'm sure others on this list, like myself, would be keen to hear of use > > > cases where the Java broker outperforms the C++ broker. > > > > > > Don't get me wrong, both brokers are extremely performant... and for > > transient messaging it's almost always going to be the network that is > the > > bottleneck. (And clearly if you have InfiniBand available, then C++ is > the > > way to go, since this is not supported in the Java). > > > > Moreover any given benchmark test result is going to be completely > > dependent on environment and you may get completely contradictory results > > on different hardware. As I said above, when evaluating performance one > > must always define the use cases that are actually going to be in play in > > the proposed deployment, and write performance testing code that tests > > those cases on your proposed hardware. It's almost always going to be > the > > case between any two Brokers A and B that for some benchmarks A >> B and > on > > others B >> A. > > > > In general where the broker is not CPU bound I've found that the two > > brokers have reasonably comparable transient messaging performance with > the > > Java Broker normally requiring a little more CPU in order to achieve the > > same task, but sometimes (especially with smaller messages) seemingly > able > > to better eke out a little higher throughput. The C++ broker seems to > have > > an advantage with large message size (32Kb or so) - again though for > > transient under load the network is probably going to be your bottleneck > > unless you have a couple of 10G ethernet cards in your machine :-) > > > > For persistent messaging the solutions have been tuned for very different > > use cases it seems, with the Java performing better when the clients are > > operating in a highly synchronous manner with high levels of concurrent > > connections. The C++ (on Linux) is obviously much better tuned for the > > asynchronous persistent messaging case where it can achieve throughputs > > much higher than the Java could aspire to due to the lack of an > > asynchronous IO API. I've not looked at the performance on Windows of the > > C++ broker with the SQL store. > > > > Cheers, > > Rob > > > > > > -- > Daryoush > > Weblog: http://onfp.blogspot.com/ >
