camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paquettd <dan.paque...@lmco.com>
Subject Re: Performance and MessageSupport.getBody (1.6.0)
Date Tue, 03 Mar 2009 15:19:23 GMT

Not only avoiding the try..catch but just running through all the reflection
code over and over again can't be cheap either.


willem.jiang wrote:
> 
> Maybe we could add some kind of type converter cache to avoid the  try
> ... catch work to improve the performance.
> 
> Willem
> 
> paquettd wrote:
>> Thank you for trying to help. I'm attaching my config file here. As you
>> can
>> see this is a contrived example I made to test performance (I used a
>> similar
>> example with some other products).
>> 
>> Essentially what's happening is a String is being sent with the
>> ProducerTemplate send method; setting the type to InOut. The string is
>> checked for lower case characters; and if it has any it goes to the
>> "capitalizer"; after that it goes to a reverser and truncator before
>> finally
>> a timestamp is put into the header (before I sent it I put a timestamp as
>> well). I run this a few thousand times; using System.nanoTime for those
>> timestamps (while not real accurate I used the same thing with other COTS
>> and the relative differences are in time are larger than the clock
>> granularity)
>> 
>> After I started seeing long processing times I used JProbe from Quest
>> Software to narrow down to the bottleneck we are talking about. JProbe
>> tells
>> me that Exception is thrown 10 times processing one of these messages....
>> so
>> when I send 1000 messages 10,000 of those exceptions are being thrown and
>> it
>> takes a very long time for the 1000 messages to get through.
>> 
>> 
>> <?xml version="1.0" encoding="UTF-8"?>
>> <beans xmlns="http://www.springframework.org/schema/beans"
>> 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
>> 
>> xmlns:camel="http://activemq.apache.org/camel/schema/spring"
>> 	xsi:schemaLocation="http://www.springframework.org/schema/beans 
>> 
>> http://www.springframework.org/schema/beans/spring-beans.xsd
>> 	http://activemq.apache.org/camel/schema/spring
>> http://activemq.apache.org/camel/schema/spring/camel-spring.xsd">
>> 
>> 	<bean id="reverser" class="camel.test.StringReverser" />
>> 	<bean id="capitalizer" class="camel.test.StringCapitalizer" />
>> 	<bean id="truncater" class="camel.test.StringTruncater">
>> 		<property name="length" value="10" />
>> 	</bean>
>>         <bean id="endTimestamper"
>> class="camel.test.transformers.HeaderTimestamper">
>>             <property name="headerKey" value="END_TIME"/>
>>         </bean>
>> 
>> 	<camelContext id="camel.test.camelcontext"
>> 		xmlns="http://activemq.apache.org/camel/schema/spring">
>> 		<template id="myCamelTemplate" defaultEndpoint="direct:test" />
>> 
>> 		<route>
>> 			<from uri="direct:test" />
>> 			<choice>
>> 				<when>
>> 					<simple>${body} regex '.*[a-x].*'</simple>
>> 					<to uri="direct:capitalizeFirst" />
>> 				</when>
>> 				<otherwise>
>> 					<to uri="direct:reverseAndTruncate" />
>> 				</otherwise>
>> 			</choice>
>> 		</route>
>> 
>> 		<route>
>> 			<from uri="direct:capitalizeFirst" />
>> 			<bean ref="capitalizer" />
>> 			<to uri="direct:reverseAndTruncate"/>
>> 		</route>
>> 
>> 		<route>
>> 			<from uri="direct:reverseAndTruncate" />
>> 			<bean ref="reverser" />
>> 			<bean ref="truncater" />
>> 			<to uri="bean:endTimestamper?method=timestamp"/>
>> 		</route>
>> 	</camelContext>
>> 
>> 	<bean id="testDriver" class="camel.test.TestDriver">
>> 		<property name="producerTemplate" ref="myCamelTemplate" />
>> 	</bean>
>> </beans>
>> 
>> 
>> 
>> Claus Ibsen-2 wrote:
>>> On Tue, Mar 3, 2009 at 1:17 AM, Willem Jiang <willem.jiang@gmail.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> If you don't want the TypeConverter to get invovled , you could use
>>>> MessageSupport.getBody() directly.
>>> Yes I am wondering if he has a .convertBodyTo in the route, so we need
>>> to see this.
>>>
>>> Or some other endpoint/producer trying to get the body as a special
>>> type, eg InputStream etc.
>>>
>>> But the route would really help.
>>>
>>>
>>>> Willem
>>>>
>>>>
>>>> On Tue, Mar 3, 2009 at 1:43 AM, paquettd <dan.paquette@lmco.com> wrote:
>>>>
>>>>> I'm not sure if it makes a difference but I'm not using JMS anywhere.
>>>>> In
>>>>> fact
>>>>> in this test everything is using "direct".
>>>>>
>>>>> Is there something I can do in the Spring DSL to hint to Camel that
>>>>> there
>>>>> is
>>>>> no conversion necessary?
>>>>>
>>>>>
>>>>> Claus Ibsen-2 wrote:
>>>>>> On Mon, Mar 2, 2009 at 5:54 PM, paquettd <dan.paquette@lmco.com>
>>>>> wrote:
>>>>>>> I've been seeing some performance problems with Camel 1.6.0 (I
have
>>>>> not
>>>>>>> tried
>>>>>>> this with previous versions yet).
>>>>>>>
>>>>>>> My profiler is pointing the finger at MessageSupport.getBody,
>>>>>>> TypeConverter.convertTo, and DefaultTypeConverter.findTypeConverter
>>>>>>> specifically
>>>>>>>
>>>>>>> findTypeConverter is always throwing a
>>>>>>> NoTypeConversionAvailableException;
>>>>>>> which is then being caught and ignored in MessageSupport.getBody;
at
>>>>>>> which
>>>>>>> point processing continues successfully.
>>>>>> This should be normal in situations where you ask the body to be
a
>>>>>> specific type which cannot be converted to.
>>>>>> To help this can you show your route and what kind of JMS messages
>>>>>> are
>>>>>> you sending.
>>>>>>
>>>>>> Camel is payload type agnostics (eg dont have to be pure XML etc.)
so
>>>>>> you can send whatever objects you like.
>>>>>> It has a rich type converter registry to be able to convert seamless
>>>>>> between types.
>>>>>>
>>>>>> This registry is loaded on demand, so you should make sure your start
>>>>>> profiling after Camel is "warm".
>>>>>>
>>>>>>
>>>>>>
>>>>>>> protected <T> T getBody(Class<T> type, Object body)
is the specific
>>>>>>> getBody
>>>>>>> in question.
>>>>>>>
>>>>>>> Is this exception an expected behavior? It's weird how the catch
>>>>> block
>>>>>>> doesn't even log a warning. Should a converter have been found?
My
>>>>>>> message
>>>>>>> payload is just a java.lang.String.
>>>>>> In the old days it returned null, but that did not work as the
>>>>>> payload
>>>>>> you were trying to convert could be null, so it was a catch-22
>>>>>> situation.
>>>>>> So we added the exception.
>>>>>>
>>>>>> But if throwing exception is expensive we could maybe add a has test
>>>>>> to avoid this exception being thrown and caught in the
>>>>>> MessageSupport.
>>>>>>
>>>>>> The exception is also meant for end users so they get a good
>>>>>> exception
>>>>>> detailing the problem if they try to convert something into eg,
>>>>>> MyFooClass and its not possible to convert to it. Instead of
>>>>>> returning
>>>>>> a null value as result.
>>>>>>
>>>>>>
>>>>>>> I suspect I've done something wrong but I don't know where to
start
>>>>>>> looking.
>>>>>>> I'm concerned with this; as I'm comparing Camel to some other
>>>>>>> message
>>>>>>> routing solutions. This is making Camel take 40 times longer
than
>>>>>>> the
>>>>>>> competition and I want to make sure I do a fair comparison.
>>>>>> We are currently rewamping the internal API in Camel 2.0 that leads
>>>>>> us
>>>>>> up to a point where we can do performance improvements when Camel
>>>>>> routes exchanges.
>>>>>> Currently it does a bit of defensive copying when it moves message
>>>>>> from node to node. The revamped API lets us do some more clever stuff
>>>>>> there to improve the speed.
>>>>>>
>>>>>> So if you are testing, eg. JMS -> JMS and want it to be really
fast
>>>>>> then of course pure JMS to JMS is faster than eg over Camel as its
a
>>>>>> very flexible and transport/protocol agnostic framework. But
>>>>>> performance improvements is on our roadmap in 2.1.
>>>>>>
>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>>> http://www.nabble.com/Performance-and-MessageSupport.getBody-%281.6.0%29-tp22291841p22291841.html
>>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> Apache Camel Committer
>>>>>>
>>>>>> Open Source Integration: http://fusesource.com
>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>
>>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Performance-and-MessageSupport.getBody-%281.6.0%29-tp22291841p22292939.html
>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>
>>>
>>> -- 
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>>
>> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Performance-and-MessageSupport.getBody-%281.6.0%29-tp22291841p22310649.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message