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.ji...@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.paque...@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.paque...@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.
