[ https://issues.apache.org/activemq/browse/CAMEL-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61948#action_61948 ]
Stephan Siano commented on CAMEL-3123: -------------------------------------- Hi Claus, sure, I can try that later today, however I do not expect much from it, because that didn't come up in my profiler run at all. In general sychronized methods are not evil as such, as long as they are really fast (total time (active cpu plus wait) of the synchronized stuff must be much smaller than the cpu time for the rest). With the trunk build my CPU time goes up to 100% so I don't expect another bottleneck (at least not on my dual core PC). When is the UUID generator used, for each message exchange? According to the link, it is sufficient to add the line <bean id="activeMQUuidGenerator" class="org.apache.camel.impl.ActiveMQUuidGenerator" /> to my spring config. Don't I have to reference it somehow in the camel context? > Performance/scalability issue for converter lookup > -------------------------------------------------- > > Key: CAMEL-3123 > URL: https://issues.apache.org/activemq/browse/CAMEL-3123 > Project: Apache Camel > Issue Type: Improvement > Components: camel-core > Affects Versions: 2.4.0 > Environment: Camel 2.4.0 on apache karaf 2.0.0 > Reporter: Stephan Siano > Assignee: Claus Ibsen > Fix For: 2.5.0 > > > In a simple HTTP->HTTP proxy scenario (whith a Jetty or a servlet endpoint, > that does not matter) I observe a very severe performance regression between > Camel 2.2.0 (as in servicemix 4.2) and camel 2.4.0 running on a apache karaf > 2.0.0 OSGi stack. On the same hardware I get a throughput of 3500 messages > per second with Camel 2.2.0, but only 210 messages per second on Camel 2.4.0 > (both servlet->HTTP). If I replace the http endpoint with a log endpoint the > throughput will be about 1500 messages per second in both cases. > I have done some profiling for this: The active CPU times as shown in the > profiler remain approximately the same for both versions, however if I > monitor wait times, I get very long wait times for > org.apache.camel.impl.DefaultMessage.getHeader(java.lang.String,java.lang.Class) > calls. If I break this down I see the > java.beans.PropertyEditorManager.findEditor(java.lang.Class) call in > org.apache.camel.impl.converter.PropertyEditorTypeConverter.convertTo(java.lang.Class,java.lang.Object). > The findEditor() method is synchronized and initializes some class loading > which takes some time. > Why is it necessary to instantiate the type converter for each message? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.