You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by boday <be...@initekconsulting.com> on 2011/06/13 23:23:21 UTC
Re: Excess usage of Bean Component - performance impacts
It just depends on your situation. Both are viable approaches...approach #1
will have slightly more overhead, but gives you greater flexibility because
your bean calls are more granular, etc.
If there is an EIP pattern that you'd like to leverage, break things up into
multiple calls and use Camel in between the calls. Otherwise, a more coarse
bean call is generally easier to read/maintain/test, etc.
Deepa wrote:
>
> hi,
>
> I am new to Camel. I find Camel a great framework.
>
> Configuring routes to invoke processing methods using bean component is an
> intutive way of organizing route.
>
> My question -
> Approach 1 - Can we use bean component (bean uris) several times?
> Ex - <camel:to uri="bean:bean1?method:postprocessing1>
> <camel:to uri="bean:bean1?method:postprocessing2Log>
> <camel:to
> uri="bean:bean1?method:postprocessing3UpdateSomeInfoInResponseObject>
> <camel:to
> uri="bean:bean1?method:postprocessing4UpdateSomeMoreInfoInResponseObject>
>
> Approach 2 -
> <camel:to uri="bean:bean1?method:postprocessing1>
>
> In postprocessing1 - Programmatically (in a modular fashion ofcourse) do
> all the post processing?
>
> Also by some basic profiling I found out approach 2 seem to give better
> performance than approach 1.
>
> Which is the recommended approach? What would be considered over usage of
> the framework.
>
> Thanks,
> Deepa
>
-----
Ben O'Day
IT Consultant -http://consulting-notes.com
--
View this message in context: http://camel.465427.n5.nabble.com/Excess-usage-of-Bean-Component-performance-impacts-tp4483913p4485766.html
Sent from the Camel - Users mailing list archive at Nabble.com.
RE: Excess usage of Bean Component - performance impacts
Posted by de...@accenture.com.
Thanks Ben / Hadrian!
Fine grain seems the way to go preferable to implement EIP.
Thanks,
Deepa
-----Original Message-----
From: Hadrian Zbarcea [mailto:hzbarcea@gmail.com]
Sent: Tuesday, June 14, 2011 3:32 AM
To: users@camel.apache.org
Subject: Re: Excess usage of Bean Component - performance impacts
I personally prefer the finer grained approach. There is a very small
overhead in terms of camel piping going fine grained and obviously
requires a bit more proficiency with camel (which comes quite quickly
though).
There are however imho huge gains stemming from encouraging a developer
to better design/architect her solution. Having multiple finer grained
tasks organized in a route (even pipeline) helps with maintenance, like
Ben said (if you need to improve something you need to
change/replace/test/redeploy) a small part of your application. It then
helps with scalability, as you can split a route and deploy parts of it
on multiple boxes or at the very least throw more threads at a
particular task. Also the dsl of the route gives a better idea of what
the processing really does (although more verbose) vs if it was one
coarse bean that needs to be documented. It is also trivial to split the
route and hide that complexity behind something like a "direct:"
endpoint if you want your routes to be smaller.
But like Ben said, it all depends on your situation.
My $0.02,
Hadrian
On 06/13/2011 05:23 PM, boday wrote:
> It just depends on your situation. Both are viable approaches...approach #1
> will have slightly more overhead, but gives you greater flexibility because
> your bean calls are more granular, etc.
>
> If there is an EIP pattern that you'd like to leverage, break things up into
> multiple calls and use Camel in between the calls. Otherwise, a more coarse
> bean call is generally easier to read/maintain/test, etc.
>
>
> Deepa wrote:
>>
>> hi,
>>
>> I am new to Camel. I find Camel a great framework.
>>
>> Configuring routes to invoke processing methods using bean component is an
>> intutive way of organizing route.
>>
>> My question -
>> Approach 1 - Can we use bean component (bean uris) several times?
>> Ex -<camel:to uri="bean:bean1?method:postprocessing1>
>> <camel:to uri="bean:bean1?method:postprocessing2Log>
>> <camel:to
>> uri="bean:bean1?method:postprocessing3UpdateSomeInfoInResponseObject>
>> <camel:to
>> uri="bean:bean1?method:postprocessing4UpdateSomeMoreInfoInResponseObject>
>>
>> Approach 2 -
>> <camel:to uri="bean:bean1?method:postprocessing1>
>>
>> In postprocessing1 - Programmatically (in a modular fashion ofcourse) do
>> all the post processing?
>>
>> Also by some basic profiling I found out approach 2 seem to give better
>> performance than approach 1.
>>
>> Which is the recommended approach? What would be considered over usage of
>> the framework.
>>
>> Thanks,
>> Deepa
>>
>
>
> -----
> Ben O'Day
> IT Consultant -http://consulting-notes.com
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Excess-usage-of-Bean-Component-performance-impacts-tp4483913p4485766.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: Excess usage of Bean Component - performance impacts
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I personally prefer the finer grained approach. There is a very small
overhead in terms of camel piping going fine grained and obviously
requires a bit more proficiency with camel (which comes quite quickly
though).
There are however imho huge gains stemming from encouraging a developer
to better design/architect her solution. Having multiple finer grained
tasks organized in a route (even pipeline) helps with maintenance, like
Ben said (if you need to improve something you need to
change/replace/test/redeploy) a small part of your application. It then
helps with scalability, as you can split a route and deploy parts of it
on multiple boxes or at the very least throw more threads at a
particular task. Also the dsl of the route gives a better idea of what
the processing really does (although more verbose) vs if it was one
coarse bean that needs to be documented. It is also trivial to split the
route and hide that complexity behind something like a "direct:"
endpoint if you want your routes to be smaller.
But like Ben said, it all depends on your situation.
My $0.02,
Hadrian
On 06/13/2011 05:23 PM, boday wrote:
> It just depends on your situation. Both are viable approaches...approach #1
> will have slightly more overhead, but gives you greater flexibility because
> your bean calls are more granular, etc.
>
> If there is an EIP pattern that you'd like to leverage, break things up into
> multiple calls and use Camel in between the calls. Otherwise, a more coarse
> bean call is generally easier to read/maintain/test, etc.
>
>
> Deepa wrote:
>>
>> hi,
>>
>> I am new to Camel. I find Camel a great framework.
>>
>> Configuring routes to invoke processing methods using bean component is an
>> intutive way of organizing route.
>>
>> My question -
>> Approach 1 - Can we use bean component (bean uris) several times?
>> Ex -<camel:to uri="bean:bean1?method:postprocessing1>
>> <camel:to uri="bean:bean1?method:postprocessing2Log>
>> <camel:to
>> uri="bean:bean1?method:postprocessing3UpdateSomeInfoInResponseObject>
>> <camel:to
>> uri="bean:bean1?method:postprocessing4UpdateSomeMoreInfoInResponseObject>
>>
>> Approach 2 -
>> <camel:to uri="bean:bean1?method:postprocessing1>
>>
>> In postprocessing1 - Programmatically (in a modular fashion ofcourse) do
>> all the post processing?
>>
>> Also by some basic profiling I found out approach 2 seem to give better
>> performance than approach 1.
>>
>> Which is the recommended approach? What would be considered over usage of
>> the framework.
>>
>> Thanks,
>> Deepa
>>
>
>
> -----
> Ben O'Day
> IT Consultant -http://consulting-notes.com
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Excess-usage-of-Bean-Component-performance-impacts-tp4483913p4485766.html
> Sent from the Camel - Users mailing list archive at Nabble.com.