[
https://issues.apache.org/activemq/browse/CAMEL-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61950#action_61950
]
Claus Ibsen commented on CAMEL-3123:
------------------------------------
Hi
Well the exchange id is created on demand, such as when being logged or
accessed. So you may have logic where the id is not used at all.
However a component can also provide their own id, such as if the id was part
of the message protocol.
I looked in the camel-jetty component and it relies on the default generator
and hence it would trigger the slower JDK UUID generator if accessed.
I have also seen users with Spring Integration having performance degration
because SI uses UUID by default.
And frankly we also only switch the UUID generator in Camel due Google App
Engine compatibility. Now that Christian Mueller added the pluggable API for
UUIDs
we can revert back to AMQ based as default, and then just plugin the JDK UUID
based on camel-gae component.
See CAMEL-3139 for some numbers I ran on my local laptop, albeit using a single
thread (easier and quick to setup).
> 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.
