qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Performance comparison for C++ and Java.
Date Wed, 25 Oct 2006 19:23:21 GMT
OK, some slightly saner performance results but still not seeing C++
slowing down.

First note I've got client and server on the same box, and the box has 2
cpus, not 8 (dual core with hyper threading so linux reports each one as
4 cpus.) so slower times than the JPM test is normal.

I built C++ optimized (-O3 -DNDEBUG), used java 1.6.0-beta2 with the
flags below and ran the test 3 times against each server.


Java broker
java -server -Xmx1024m -Damqj.logging.level=fatal
-DQPID_HOME=/home/aconway/svn/qpid/java/build -DQPID_WORK=/home/aconway
Broker started: qpid-server
20 batches completed. avg=3169, max=6140, min=2473
20 batches completed. avg=2672, max=3094, min=2270
20 batches completed. avg=2672, max=3137, min=2335

C++ broker
Broker started: qpidd
20 batches completed. avg=1973, max=3340, min=1701
20 batches completed. avg=2028, max=2445, min=1891
20 batches completed. avg=2141, max=2613, min=1908

Still lots slower than JPM but that's reasonable given 2 vs. 8 CPUs and
clients+server on same box. The Java broker does indeed have a warm-up
issue so we'll ignore the first test run against it.

C++ broker remains faster by about 20%. 

Robert, Martin can either of you try this on the JPM machine? I've
attached my test scripts, put them in your path. Add qpid/cpp/bin and
qpid/cpp/test/client to the path then run topicall. 

On Mon, 2006-10-23 at 13:48 +0100, Martin Ritchie wrote:
> I have run the test as described above. The only deviation may have
> been setting -Xmx1024M. Although this is the default set by the
> scripts.
> The broker was restarted between test and the SVN revision was: 466043.
> I ran the tests twice:
> 1) All processes on a single box.
> 2) Broker on 8 way opteron, Clients on 4 way opteron.
> Unfortunately we cannot get exclusive access to these boxes however
> the loading on the machines are quite low.
> In both cases a significant performance increase was shown. I believe
> this is down to memory usage. The test utilises around 2.2G of RAM
> which may have caused a problem on the test box at Redhat.

View raw message