qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryoush Mehrtash <dmehrt...@gmail.com>
Subject Re: C++ and Java brokers
Date Thu, 05 Jan 2012 21:56:41 GMT
>
> 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.

Thanks

Daryoush


On Thu, Jan 5, 2012 at 1:39 PM, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:

> On 5 January 2012 20:39, William Henry <whenry@redhat.com> 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message