camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: ESB Performance Testing - Round 6
Date Wed, 29 Aug 2012 14:20:20 GMT

(responding to both Claus and Christian)

On Aug 29, 2012, at 3:11 AM, Claus Ibsen <> wrote:

> On Tue, Aug 28, 2012 at 11:07 PM, Christian Müller
> <> wrote:
>> You may know the last ESB performance test results from round 6 [1].
>> As you can see, Apache ServiceMix 4.3.0 failed to complete this benchmark.
>> These tests are still based on the deprecated Apache ServiceMix JBI
>> components.
> First of all I think this test is single eye-sided on the area that
> the people behind the tests,
> is the areas where their solution is as its bests = only WS. And its
> not a general purpose tests to show
> all areas of the ESB. eg its only webservice based!

Well, feel free to propose new test cases.   I do know that for Round 7, they want to add
a bunch of REST based tests, but no ideas on what they may look like yet.

>> Because of this, I implemented the required tests for Apache ServiceMix
>> 4.4.2 and Apache Camel (2.8.5) - instead of using JBI. I hope we can pass
>> the tests this time…

Well, I would have expected SOME credit for this since you obviously started with much of
the work I did for Talend ESB…….     ;-)

Also have to be careful about sticking the Apache license header on some of those (particularly
the ws-security context.xml).   I have no idea what the original license is.  I never really
asked about that.   Likely Apache or Apache compatible, but I really have no idea.  

> I guess when the time comes it makes sense to use SMX 4.5.0 with Camel
> 2.10.x and CXF 2.6.x to get the latest stuff.
> Especially since both Camel and CXF in these releases have been
> improved in the streaming areas of XML / CXF stuff.
> I am not sure though how much this applies to the tests where you run
> in MESSAGE mode in camel-cxf.

Not much.  :-)    A lot of those performance enhancements were done before I flipped the Talend
tests over to MESSAGE.    Once I flipped them to MESSAGE, it pretty much bypassed most of
the work I did optimizing the streaming payload.  The ws-security tests would benefit a bit,
but not much.   The streaming payload stuff is great and certainly helps in a bunch of scenarios,
but not this one anymore.  

>> Feel free to provide any feedback. May you find places where we can make
> As the tests uses big/medium payloads 50kb, 100kb etc. and you have
> enable stream caching in the code, then mind the default threshold for
> spooling to disk is at 64kb limit. And when you spool to disk its
> freaking slow compared to be kept in memory.
> And its using the slow API and not any NIO memory mapped
> files etc instead.
> You can set an option to increase the threshold, to keep the messages in memory

Actually, I did look at this and for these tests, it doesn't matter.    The only time the
tests go to 100K is in the direct proxy case.   The other 5 tests top out at 10K.    The direct
proxy doesn't cache the streams so the setting isn't needed for these tests.   It is something
to keep an eye on if they add larger tests.  (example: between round 5 and 6, I had them add
larger ws-security  tests as ws-security is important for me and I wanted to see how it behaved
as the messages got a little larget)


> Also I wonder if using OSGi blueprint would be better than the old
> aging spring-dm 1.2.
> And I guess the SMX can be trimmed down in size. Maybe with its
> minimal configuration etc.
> eg to drop all the legacy JBI and whatnot it carries by default.
>> Apache ServiceMix and/or Apache Camel faster.
>> You can find my Mercurial repo at [2] and my Git repo at [3].
>> [1]
>> [2]
>> [3]
>> Best,
>> Christian
>> --
> -- 
> Claus Ibsen
> -----------------
> FuseSource
> Email:
> Web:
> Twitter: davsclaus, fusenews
> Blog:
> Author of Camel in Action:

Daniel Kulp -
Talend Community Coder -

View raw message