You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by aedwards <ad...@middleware360.com> on 2012/07/15 04:52:11 UTC
fyi - SI
http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
--
View this message in context: http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: fyi - SI
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
When using a reply queue its shared by default, so you would need to
specify replyToType=Exclusive to mark the reply queue as exclusive to
this particular Camel consumer. And then its much faster.
I gave the sample code a test run on my laptop. The only change i did
was to mark it as exclusive
<to uri="jms:jmsCamelQueue?replyTo=bar&replyToType=Exclusive&connectionFactory=connectionFactory"
pattern="InOut" />
2012-07-15 21:49:35,943 [main ] INFO
ClassPathXmlApplicationContext - Refreshing
org.springframework.context.support.ClassPathXmlApplicationContext@19d009b4:
startup date [Sun Jul 15 21:49:35 CEST 2012]; root of context
hierarchy
2012-07-15 21:49:36,000 [main ] INFO
XmlBeanDefinitionReader - Loading XML bean definitions from
class path resource [camel/../camel-consumer.xml]
2012-07-15 21:49:37,359 [main ] INFO
DefaultListableBeanFactory - Pre-instantiating singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@5e6ffd79:
defining beans [myService,template,consumerTemplate,camel-1:beanPostProcessor,camel-1,connectionFactory];
root of factory hierarchy
2012-07-15 21:49:37,657 [main ] INFO SpringCamelContext
- Apache Camel 2.10.0 (CamelContext: camel-1) is starting
2012-07-15 21:49:37,756 [main ] INFO
ManagementStrategyFactory - JMX enabled.
2012-07-15 21:49:37,757 [main ] INFO
ultManagementLifecycleStrategy - StatisticsLevel at All so enabling
load performance statistics
2012-07-15 21:49:37,938 [main ] INFO DefaultTypeConverter
- Loaded 173 type converters
2012-07-15 21:49:38,498 [main ] INFO
CachingConnectionFactory - Established shared JMS Connection:
ActiveMQConnection
{id=ID:davsclaus.lan-51059-1342381778383-1:1,clientId=null,started=false}
2012-07-15 21:49:38,536 [main ] INFO SpringCamelContext
- Route: route1 started and consuming from:
Endpoint[jms://jmsCamelQueue?connectionFactory=connectionFactory]
2012-07-15 21:49:38,540 [main ] INFO SpringCamelContext
- Total 1 routes, of which 1 is started.
2012-07-15 21:49:38,549 [main ] INFO SpringCamelContext
- Apache Camel 2.10.0 (CamelContext: camel-1) started in 0.883
seconds
2012-07-15 21:49:38,554 [main ] INFO
ClassPathXmlApplicationContext - Refreshing
org.springframework.context.support.ClassPathXmlApplicationContext@6212f195:
startup date [Sun Jul 15 21:49:38 CEST 2012]; root of context
hierarchy
2012-07-15 21:49:38,554 [main ] INFO
XmlBeanDefinitionReader - Loading XML bean definitions from
class path resource [camel/../camel-producer.xml]
2012-07-15 21:49:39,317 [main ] INFO
DefaultListableBeanFactory - Pre-instantiating singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@425113f0:
defining beans [template,consumerTemplate,camel:beanPostProcessor,camel,activemq,connectionFactory];
root of factory hierarchy
2012-07-15 21:49:39,345 [main ] INFO SpringCamelContext
- Apache Camel 2.10.0 (CamelContext: camel) is starting
2012-07-15 21:49:39,345 [main ] INFO
ManagementStrategyFactory - JMX enabled.
2012-07-15 21:49:39,346 [main ] INFO
ultManagementLifecycleStrategy - StatisticsLevel at All so enabling
load performance statistics
2012-07-15 21:49:39,384 [main ] INFO DefaultTypeConverter
- Loaded 173 type converters
2012-07-15 21:49:39,583 [main ] INFO SpringCamelContext
- Route: route2 started and consuming from:
Endpoint[direct://invokeJmsCamelQueue]
2012-07-15 21:49:39,585 [main ] INFO SpringCamelContext
- Total 1 routes, of which 1 is started.
2012-07-15 21:49:39,585 [main ] INFO SpringCamelContext
- Apache Camel 2.10.0 (CamelContext: camel) started in 0.240
seconds
2012-07-15 21:49:39,631 [main ] INFO
CachingConnectionFactory - Established shared JMS Connection:
ActiveMQConnection
{id=ID:davsclaus.lan-51059-1342381778383-3:1,clientId=null,started=false}
Exchanged 1000 messages in 2356 millis
Exchanged 1000 messages in 1428 millis
Exchanged 1000 messages in 1430 millis
Exchanged 1000 messages in 1267 millis
Exchanged 1000 messages in 1099 millis
Exchanged 1000 messages in 1911 millis
Exchanged 1000 messages in 758 millis
Exchanged 1000 messages in 714 millis
Exchanged 1000 messages in 701 millis
Exchanged 1000 messages in 854 millis
Exchanged 1000 messages in 909 millis
Exchanged 1000 messages in 633 millis
Exchanged 1000 messages in 630 millis
Exchanged 1000 messages in 621 millis
Exchanged 1000 messages in 650 millis
Exchanged 1000 messages in 617 millis
Exchanged 1000 messages in 621 millis
Exchanged 1000 messages in 634 millis
Exchanged 1000 messages in 609 millis
Exchanged 1000 messages in 619 millis
Exchanged 1000 messages in 616 millis
Exchanged 1000 messages in 615 millis
Exchanged 1000 messages in 616 millis
Exchanged 1000 messages in 610 millis
Exchanged 1000 messages in 671 millis
Exchanged 1000 messages in 663 millis
Exchanged 1000 messages in 629 millis
Exchanged 1000 messages in 672 millis
Exchanged 1000 messages in 668 millis
Exchanged 1000 messages in 675 millis
Exchanged 1000 messages in 619 millis
Exchanged 1000 messages in 641 millis
Exchanged 1000 messages in 609 millis
Exchanged 1000 messages in 635 millis
Exchanged 1000 messages in 658 millis
Exchanged 1000 messages in 616 millis
Exchanged 1000 messages in 631 millis
Exchanged 1000 messages in 619 millis
Exchanged 1000 messages in 664 millis
Exchanged 1000 messages in 694 millis
Exchanged 1000 messages in 632 millis
Exchanged 1000 messages in 615 millis
Exchanged 1000 messages in 634 millis
Exchanged 1000 messages in 708 millis
Exchanged 1000 messages in 631 millis
Exchanged 1000 messages in 618 millis
Exchanged 1000 messages in 613 millis
Exchanged 1000 messages in 630 millis
Exchanged 1000 messages in 616 millis
Exchanged 1000 messages in 610 millis
Exchanged 1000 messages in 672 millis
Exchanged 1000 messages in 633 millis
And running the SI sample out of the box on my laptop yields these
number. They are using the same broker that has been running all time
along.
2012-07-15 21:52:52,258 [main ] INFO
ClassPathXmlApplicationContext - Refreshing
org.springframework.context.support.ClassPathXmlApplicationContext@77827284:
startup date [Sun Jul 15 21:52:52 CEST 2012]; root of context
hierarchy
2012-07-15 21:52:52,327 [main ] INFO
XmlBeanDefinitionReader - Loading XML bean definitions from
class path resource [si/../consumer.xml]
2012-07-15 21:52:52,863 [main ] INFO
guringBeanFactoryPostProcessor - No bean named 'errorChannel' has been
explicitly defined. Therefore, a default PublishSubscribeChannel will
be created.
2012-07-15 21:52:52,863 [main ] INFO
guringBeanFactoryPostProcessor - No bean named 'taskScheduler' has
been explicitly defined. Therefore, a default ThreadPoolTaskScheduler
will be created.
2012-07-15 21:52:52,880 [main ] INFO
DefaultListableBeanFactory - Pre-instantiating singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@1a50ca0c:
defining beans [channelInitializer,$autoCreateChannelCandidates,org.springframework.integration.internalDefaultConfiguringBeanFactoryPostProcessor,org.springframework.jms.listener.DefaultMessageListenerContainer#0,org.springframework.integration.jms.ChannelPublishingJmsMessageListener#0,org.springframework.integration.jms.JmsMessageDrivenEndpoint#0,org.springframework.integration.config.TransformerFactoryBean#0,org.springframework.integration.config.ConsumerEndpointFactoryBean#0,connectionFactory,nullChannel,errorChannel,_org.springframework.integration.errorLogger,taskScheduler,org.springframework.integration.config.IdGeneratorConfigurer#0];
root of factory hierarchy
2012-07-15 21:52:53,157 [main ] INFO
ThreadPoolTaskScheduler - Initializing ExecutorService
'taskScheduler'
2012-07-15 21:52:53,162 [main ] INFO
DefaultLifecycleProcessor - Starting beans in phase -2147483648
2012-07-15 21:52:53,162 [main ] INFO EventDrivenConsumer
- Adding {transformer} as a subscriber to the 'jmsIn' channel
2012-07-15 21:52:53,162 [main ] INFO DirectChannel
- Channel 'jmsIn' has 1 subscriber(s).
2012-07-15 21:52:53,162 [main ] INFO EventDrivenConsumer
- started
org.springframework.integration.config.ConsumerEndpointFactoryBean#0
2012-07-15 21:52:53,162 [main ] INFO EventDrivenConsumer
- Adding
{logging-channel-adapter:_org.springframework.integration.errorLogger}
as a subscriber to the 'errorChannel' channel
2012-07-15 21:52:53,163 [main ] INFO
PublishSubscribeChannel - Channel 'errorChannel' has 1
subscriber(s).
2012-07-15 21:52:53,163 [main ] INFO EventDrivenConsumer
- started _org.springframework.integration.errorLogger
2012-07-15 21:52:53,163 [main ] INFO
DefaultLifecycleProcessor - Starting beans in phase 0
2012-07-15 21:52:53,365 [main ] INFO
CachingConnectionFactory - Established shared JMS Connection:
ActiveMQConnection
{id=ID:davsclaus.lan-51092-1342381973248-1:1,clientId=null,started=false}
2012-07-15 21:52:53,391 [main ] INFO
essageListener$GatewayDelegate - started
org.springframework.integration.jms.ChannelPublishingJmsMessageListener$GatewayDelegate@72e5355f
2012-07-15 21:52:53,391 [main ] INFO
JmsMessageDrivenEndpoint - started
org.springframework.integration.jms.JmsMessageDrivenEndpoint#0
2012-07-15 21:52:53,416 [main ] INFO
ClassPathXmlApplicationContext - Refreshing
org.springframework.context.support.ClassPathXmlApplicationContext@40bc5596:
startup date [Sun Jul 15 21:52:53 CEST 2012]; root of context
hierarchy
2012-07-15 21:52:53,420 [main ] INFO
XmlBeanDefinitionReader - Loading XML bean definitions from
class path resource [si/../producer.xml]
2012-07-15 21:52:53,626 [main ] INFO
guringBeanFactoryPostProcessor - No bean named 'errorChannel' has been
explicitly defined. Therefore, a default PublishSubscribeChannel will
be created.
2012-07-15 21:52:53,626 [main ] INFO
guringBeanFactoryPostProcessor - No bean named 'taskScheduler' has
been explicitly defined. Therefore, a default ThreadPoolTaskScheduler
will be created.
2012-07-15 21:52:53,629 [main ] INFO
DefaultListableBeanFactory - Pre-instantiating singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@4125d61e:
defining beans [channelInitializer,$autoCreateChannelCandidates,org.springframework.integration.internalDefaultConfiguringBeanFactoryPostProcessor,org.springframework.integration.gateway.GatewayProxyFactoryBean#0,inputChannel,org.springframework.integration.jms.JmsOutboundGateway#0,org.springframework.integration.config.ConsumerEndpointFactoryBean#0,connectionFactory,nullChannel,errorChannel,_org.springframework.integration.errorLogger,taskScheduler,org.springframework.integration.config.IdGeneratorConfigurer#0];
root of factory hierarchy
2012-07-15 21:52:53,644 [main ] INFO
ThreadPoolTaskScheduler - Initializing ExecutorService
'taskScheduler'
2012-07-15 21:52:53,663 [main ] INFO
ryBean$MethodInvocationGateway - started
org.springframework.integration.gateway.GatewayProxyFactoryBean#0
2012-07-15 21:52:53,663 [main ] INFO
GatewayProxyFactoryBean - started
org.springframework.integration.gateway.GatewayProxyFactoryBean#0
2012-07-15 21:52:53,697 [main ] INFO
DefaultLifecycleProcessor - Starting beans in phase -2147483648
2012-07-15 21:52:53,697 [main ] INFO EventDrivenConsumer
- Adding {jms:outbound-gateway} as a subscriber to the 'jmsIn'
channel
2012-07-15 21:52:53,697 [main ] INFO DirectChannel
- Channel 'jmsIn' has 1 subscriber(s).
2012-07-15 21:52:53,697 [main ] INFO EventDrivenConsumer
- started
org.springframework.integration.config.ConsumerEndpointFactoryBean#0
2012-07-15 21:52:53,697 [main ] INFO EventDrivenConsumer
- Adding
{logging-channel-adapter:_org.springframework.integration.errorLogger}
as a subscriber to the 'errorChannel' channel
2012-07-15 21:52:53,697 [main ] INFO
PublishSubscribeChannel - Channel 'errorChannel' has 1
subscriber(s).
2012-07-15 21:52:53,697 [main ] INFO EventDrivenConsumer
- started _org.springframework.integration.errorLogger
2012-07-15 21:52:53,698 [main ] INFO
DefaultLifecycleProcessor - Starting beans in phase 0
2012-07-15 21:52:53,963 [main ] INFO
CachingConnectionFactory - Established shared JMS Connection:
ActiveMQConnection
{id=ID:davsclaus.lan-51092-1342381973248-3:1,clientId=null,started=false}
Exchanged 1000 messages in 3504
Exchanged 1000 messages in 3238
Exchanged 1000 messages in 2421
Exchanged 1000 messages in 1869
Exchanged 1000 messages in 1891
Exchanged 1000 messages in 3504
Exchanged 1000 messages in 1531
Exchanged 1000 messages in 1730
Exchanged 1000 messages in 1476
Exchanged 1000 messages in 1690
Exchanged 1000 messages in 1823
Exchanged 1000 messages in 1352
Exchanged 1000 messages in 1542
Exchanged 1000 messages in 1343
Exchanged 1000 messages in 1306
Exchanged 1000 messages in 1269
Exchanged 1000 messages in 1293
Exchanged 1000 messages in 1439
Exchanged 1000 messages in 1362
Exchanged 1000 messages in 1335
Exchanged 1000 messages in 1466
Exchanged 1000 messages in 1301
Exchanged 1000 messages in 1260
Exchanged 1000 messages in 1349
Exchanged 1000 messages in 1528
Exchanged 1000 messages in 1349
Exchanged 1000 messages in 1352
Exchanged 1000 messages in 1456
Exchanged 1000 messages in 1517
Exchanged 1000 messages in 1344
Exchanged 1000 messages in 1394
Exchanged 1000 messages in 1316
Exchanged 1000 messages in 1365
Exchanged 1000 messages in 1406
Exchanged 1000 messages in 1375
Exchanged 1000 messages in 1364
Exchanged 1000 messages in 1427
Exchanged 1000 messages in 1483
Exchanged 1000 messages in 1413
Exchanged 1000 messages in 1490
I am using the latest SI release 2.1.2, with Spring 3.0.7. And for
Camel it was the latest 2.10.0 release.
All running on Java6
davsclaus:~/Downloads/jms-request-reply/camel$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /opt/apache-maven-3.0.4
Java version: 1.6.0_33, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac"
The dependency tree from Maven. I put all the src in the same maven
project, to make it easier to start the apps from my IDEA editor.
And I named the project camel-foo.
[INFO] --- maven-dependency-plugin:2.4:tree (default-cli) @ camel-foo ---
[INFO] org.apache.camel:camel-foo:jar:2.10.0
[INFO] +- org.springframework.integration:spring-integration-core:jar:2.1.2.RELEASE:compile
[INFO] | +- org.springframework:spring-aop:jar:3.0.7.RELEASE:compile
[INFO] | | +- aopalliance:aopalliance:jar:1.0:compile
[INFO] | | \- org.springframework:spring-asm:jar:3.0.7.RELEASE:compile
[INFO] | \- org.springframework:spring-context:jar:3.0.7.RELEASE:compile
[INFO] | \- org.springframework:spring-expression:jar:3.0.7.RELEASE:compile
[INFO] +- org.springframework.integration:spring-integration-jms:jar:2.1.2.RELEASE:compile
[INFO] | +- org.springframework:spring-tx:jar:3.0.7.RELEASE:compile
[INFO] | \- org.springframework:spring-jms:jar:3.0.7.RELEASE:compile
[INFO] +- org.apache.camel:camel-spring:jar:2.10.0:compile
[INFO] | \- org.apache.camel:camel-core:jar:2.10.0:compile
[INFO] +- org.apache.camel:camel-jms:jar:2.10.0:compile
[INFO] | +- org.springframework:spring-core:jar:3.0.7.RELEASE:compile
[INFO] | | \- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] | \- org.springframework:spring-beans:jar:3.0.7.RELEASE:compile
[INFO] +- org.apache.activemq:activemq-core:jar:5.6.0:compile
[INFO] | +- org.slf4j:slf4j-api:jar:1.6.1:compile
[INFO] | +- org.apache.geronimo.specs:geronimo-jms_1.1_spec:jar:1.1.1:compile
[INFO] | +- org.apache.activemq:kahadb:jar:5.6.0:compile
[INFO] | +- org.apache.activemq.protobuf:activemq-protobuf:jar:1.1:compile
[INFO] | +- org.fusesource.fuse-extra:fusemq-leveldb:jar:1.1:compile
[INFO] | | +- org.fusesource.hawtbuf:hawtbuf-proto:jar:1.9:compile
[INFO] | | +- org.fusesource.hawtdispatch:hawtdispatch-scala:jar:1.9:compile
[INFO] | | | \- org.fusesource.hawtdispatch:hawtdispatch:jar:1.9:compile
[INFO] | | +- org.iq80.leveldb:leveldb:jar:0.2:compile
[INFO] | | | +- org.iq80.leveldb:leveldb-api:jar:0.2:compile
[INFO] | | | +- com.google.inject:guice:jar:3.0:compile
[INFO] | | | | \- javax.inject:javax.inject:jar:1:compile
[INFO] | | | +-
com.google.inject.extensions:guice-multibindings:jar:3.0:compile
[INFO] | | | \- com.google.guava:guava:jar:10.0.1:compile
[INFO] | | | \- com.google.code.findbugs:jsr305:jar:1.3.9:compile
[INFO] | | +- org.fusesource.leveldbjni:leveldbjni-osx:jar:1.2:compile
[INFO] | | | \- org.fusesource.leveldbjni:leveldbjni:jar:1.2:compile
[INFO] | | | \- org.fusesource.hawtjni:hawtjni-runtime:jar:1.5:compile
[INFO] | | +- org.fusesource.leveldbjni:leveldbjni-linux32:jar:1.2:compile
[INFO] | | +- org.fusesource.leveldbjni:leveldbjni-linux64:jar:1.2:compile
[INFO] | | +- org.xerial.snappy:snappy-java:jar:1.0.3:compile
[INFO] | | +- org.codehaus.jackson:jackson-core-asl:jar:1.9.2:compile
[INFO] | | +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.2:compile
[INFO] | | +- org.apache.hadoop:hadoop-core:jar:1.0.3:compile
(version managed from 1.0.0)
[INFO] | | | +- commons-configuration:commons-configuration:jar:1.6:compile
[INFO] | | | | +- commons-collections:commons-collections:jar:3.2.1:compile
[INFO] | | | | +- commons-lang:commons-lang:jar:2.4:compile
[INFO] | | | | +- commons-digester:commons-digester:jar:1.8:compile
[INFO] | | | | | \- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] | | | | \- commons-beanutils:commons-beanutils-core:jar:1.8.0:compile
[INFO] | | | +- org.mortbay.jetty:jetty:jar:6.1.26:compile
[INFO] | | | | \- org.mortbay.jetty:servlet-api:jar:2.5-20081211:compile
[INFO] | | | +- org.mortbay.jetty:jetty-util:jar:6.1.26:compile
[INFO] | | | +- org.mortbay.jetty:jsp-api-2.1:jar:6.1.14:compile
[INFO] | | | | \- org.mortbay.jetty:servlet-api-2.5:jar:6.1.14:compile
[INFO] | | | \- org.mortbay.jetty:jsp-2.1:jar:6.1.14:compile
[INFO] | | | \- ant:ant:jar:1.6.5:compile
[INFO] | | \- org.scala-lang:scala-library:jar:2.9.1:compile
[INFO] | +- org.fusesource.mqtt-client:mqtt-client:jar:1.0:compile
[INFO] | | +-
org.fusesource.hawtdispatch:hawtdispatch-transport:jar:1.9:compile
[INFO] | | \- org.fusesource.hawtbuf:hawtbuf:jar:1.9:compile
[INFO] | +- org.osgi:org.osgi.core:jar:4.2.0:compile (version managed
from 4.1.0)
[INFO] | +- org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec:jar:1.0.1:compile
[INFO] | +- commons-net:commons-net:jar:2.2:compile
[INFO] | \- org.jasypt:jasypt:jar:1.8:compile
[INFO] +- org.apache.activemq:activemq-camel:jar:5.6.0:compile
[INFO] +- org.apache.activemq:activemq-pool:jar:5.6.0:compile
[INFO] | +- org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.0.1:compile
[INFO] | \- commons-pool:commons-pool:jar:1.6:compile (version
managed from 1.5.6)
[INFO] +- org.slf4j:slf4j-log4j12:jar:1.6.6:compile
[INFO] +- log4j:log4j:jar:1.2.16:compile
[INFO] \- junit:junit:jar:4.10:test
[INFO] \- org.hamcrest:hamcrest-core:jar:1.1:test
[INFO] ------------------------------------------------------------------------
On Sun, Jul 15, 2012 at 4:52 AM, aedwards <ad...@middleware360.com> wrote:
> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: fyi - SI
Posted by Johan Edstrom <se...@gmail.com>.
But is it better?
</end bad joke>
On Jul 15, 2012, at 4:36 PM, Christian Müller wrote:
> Thanks Adam for this pointer.
> I respond to this thread with an optimized version of the Camel route which
> is about two times faster than the Spring integration solution.
>
> Best,
> Christian
>
> On Sun, Jul 15, 2012 at 4:52 AM, aedwards <ad...@middleware360.com> wrote:
>
>>
>> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
Re: fyi - SI
Posted by Christian Müller <ch...@gmail.com>.
I like these numbers...
Christian
Sent from a mobile device
Am 06.08.2012 08:06 schrieb "Scott England-Sullivan" <su...@gmail.com>:
> Hi All,
>
> As a follow up to this thread, I wanted to see where SJMS stacked up
> against these results. Using the tests provided that included the
> optimized Camel route from Clause, I ran the same tests against the the new
> SJMS component with the following result:
>
> [ main] SpringCamelContext INFO
> Apache Camel 2.11-SNAPSHOT (CamelContext: camel) started in 0.201 seconds
> Exchanged 1000 messages in 1279 millis
> Exchanged 1000 messages in 893 millis
> Exchanged 1000 messages in 830 millis
> Exchanged 1000 messages in 676 millis
> Exchanged 1000 messages in 628 millis
> Exchanged 1000 messages in 624 millis
> Exchanged 1000 messages in 450 millis
> Exchanged 1000 messages in 447 millis
> Exchanged 1000 messages in 445 millis
> Exchanged 1000 messages in 449 millis
> Exchanged 1000 messages in 453 millis
> Exchanged 1000 messages in 395 millis
> Exchanged 1000 messages in 401 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 385 millis
> Exchanged 1000 messages in 389 millis
> Exchanged 1000 messages in 389 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 387 millis
> Exchanged 1000 messages in 387 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 386 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 386 millis
> Exchanged 1000 messages in 389 millis
> Exchanged 1000 messages in 385 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 385 millis
> Exchanged 1000 messages in 389 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 386 millis
> Exchanged 1000 messages in 393 millis
> Exchanged 1000 messages in 392 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 391 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 398 millis
> Exchanged 1000 messages in 394 millis
> Exchanged 1000 messages in 394 millis
> Exchanged 1000 messages in 397 millis
> Exchanged 1000 messages in 391 millis
> Exchanged 1000 messages in 395 millis
> Exchanged 1000 messages in 391 millis
> Exchanged 1000 messages in 392 millis
> Exchanged 1000 messages in 392 millis
> Exchanged 1000 messages in 391 millis
> Exchanged 1000 messages in 392 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 393 millis
> Exchanged 1000 messages in 390 millis
>
>
> For comparison against the same environment here are the optimized Camel
> JMS numbers:
>
>
> [ main] SpringCamelContext INFO
> Apache Camel 2.11-SNAPSHOT (CamelContext: camel) started in 0.123 seconds
> Exchanged 1000 messages in 1367 millis
> Exchanged 1000 messages in 978 millis
> Exchanged 1000 messages in 857 millis
> Exchanged 1000 messages in 740 millis
> Exchanged 1000 messages in 703 millis
> Exchanged 1000 messages in 732 millis
> Exchanged 1000 messages in 636 millis
> Exchanged 1000 messages in 497 millis
> Exchanged 1000 messages in 476 millis
> Exchanged 1000 messages in 479 millis
> Exchanged 1000 messages in 465 millis
> Exchanged 1000 messages in 437 millis
> Exchanged 1000 messages in 428 millis
> Exchanged 1000 messages in 428 millis
> Exchanged 1000 messages in 423 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 420 millis
> Exchanged 1000 messages in 417 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 415 millis
> Exchanged 1000 messages in 420 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 419 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 415 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 419 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 420 millis
> Exchanged 1000 messages in 421 millis
> Exchanged 1000 messages in 420 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 417 millis
> Exchanged 1000 messages in 424 millis
> Exchanged 1000 messages in 421 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 421 millis
> Exchanged 1000 messages in 419 millis
> Exchanged 1000 messages in 427 millis
> Exchanged 1000 messages in 426 millis
> Exchanged 1000 messages in 427 millis
> Exchanged 1000 messages in 429 millis
> Exchanged 1000 messages in 425 millis
> Exchanged 1000 messages in 424 millis
>
> :)
>
> On Mon, Jul 16, 2012 at 5:07 PM, Christian Müller <
> christian.mueller@gmail.com> wrote:
>
> > On Mon, Jul 16, 2012 at 10:04 PM, Claus Ibsen <cl...@gmail.com>
> > wrote:
> >
> > > On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller
> > > <ch...@gmail.com> wrote:
> > > > Great explanation Claus. I answered in the SI forum to make this
> clear
> > > for
> > > > them.
> > > >
> > >
> > > Well you could match the examples a bit more. The SI sends directly
> > > from the java code to a the JMS queue.
> > > Where as in Camel its send to a direct endpoint in a Camel route, and
> > > then to the JMS queue.
> > > You could omit the Camel route, and send directly the the JMS queue,
> > > like SI does.
> > >
> > This is what my sample do.
> >
> > >
> > > Also disabling JMX performance stats may make a difference, but only
> > > for really high end performance.
> > > In this example its more the TCP / remote bandwith that is the
> > > bottleneck, and the CPU cycles to calculate performance stats for JMX.
> > >
> > > Also in Camel you can disable persistent on request/reply when sending
> > > (eg replyToDeliveryPersistent=false) but SI is sending persistent as
> > > well. But as an end user you may want this in case you are okay with
> > > sending the msg as non persistent to the broker.
> > >
> > > Also SI is having 10 concurrent consumers on the consumer side. Where
> > > as Camel has 1 consumer only. But that dont matter as much as the
> > > processing is just sending back the same message.
> > >
> > Yes, I tested it also with 10 consumers and came up to the same
> conclusion.
> >
> > >
> > > In Camel you send the message to a bean, without giving a method name.
> > > Which forces Camel to instrospect the bean on the invocation. A better
> > > solution to match SI would to use the message translator EIP
> > >
> > > <transform><simple>${body}</simple></transform>
> > >
> > > To just transform the reply to the incoming message.
> > >
> > Yes, indeed. I will make an additional test with this config and publish
> > it. My last post was not accepted on the forum...
> >
> > >
> > >
> > > > Best,
> > > > Christian
> > > >
> > > > On Mon, Jul 16, 2012 at 8:03 AM, Claus Ibsen <cl...@gmail.com>
> > > wrote:
> > > >
> > > >> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
> > > >> <ch...@gmail.com> wrote:
> > > >> > Thanks Adam for this pointer.
> > > >> > I respond to this thread with an optimized version of the Camel
> > route
> > > >> which
> > > >> > is about two times faster than the Spring integration solution.
> > > >> >
> > > >>
> > > >> Btw the default request/reply with Camel JMS is using temporary
> > > >> queues, eg do not specify a replyTo queue name. The temporary queues
> > > >> is like exclusive, and fast.
> > > >>
> > > >> The shared queues are for clustered / and/or if the queue is used
> for
> > > >> other purposes/other apps etc. eg in some brokers its not
> > > >> easy/possible to create new queues on the fly etc.
> > > >>
> > > >> And the shared option was the default from the early days of the
> Camel
> > > >> project, and we have kept the shared as default since.
> > > >>
> > > >> Its of course documented in the JMS page. But I guess SI people
> don't
> > > >> read the docs
> > > >> http://camel.apache.org/jms (request/reply section)
> > > >>
> > > >> I logged a ticket to add some logging when shared queues are in use,
> > > >> so the end user may notice this more easier, than go read the JMS
> docs
> > > >> https://issues.apache.org/jira/browse/CAMEL-5444
> > > >>
> > > >> > Best,
> > > >> > Christian
> > > >> >
> > > >> > On Sun, Jul 15, 2012 at 4:52 AM, aedwards <adam@middleware360.com
> >
> > > >> wrote:
> > > >> >
> > > >> >>
> > > >> >>
> > > >>
> > >
> >
> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> View this message in context:
> > > >> >> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
> > > >> >> Sent from the Camel Development mailing list archive at
> Nabble.com.
> > > >> >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Claus Ibsen
> > > >> -----------------
> > > >> FuseSource
> > > >> Email: cibsen@fusesource.com
> > > >> Web: http://fusesource.com
> > > >> Twitter: davsclaus, fusenews
> > > >> Blog: http://davsclaus.com
> > > >> Author of Camel in Action: http://www.manning.com/ibsen
> > > >>
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -----------------
> > > FuseSource
> > > Email: cibsen@fusesource.com
> > > Web: http://fusesource.com
> > > Twitter: davsclaus, fusenews
> > > Blog: http://davsclaus.com
> > > Author of Camel in Action: http://www.manning.com/ibsen
> > >
> >
>
>
>
> --
> --
> Scott England-Sullivan
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://sully6768.blogspot.com
> Twitter: sully6768
>
Re: fyi - SI
Posted by Willem jiang <wi...@gmail.com>.
Cool, that is a good test result for advertising the simple jms component.
--
Willem Jiang
On Monday, August 6, 2012 at 2:06 PM, Scott England-Sullivan wrote:
> Hi All,
>
> As a follow up to this thread, I wanted to see where SJMS stacked up
> against these results. Using the tests provided that included the
> optimized Camel route from Clause, I ran the same tests against the the new
> SJMS component with the following result:
>
> [ main] SpringCamelContext INFO
> Apache Camel 2.11-SNAPSHOT (CamelContext: camel) started in 0.201 seconds
> Exchanged 1000 messages in 1279 millis
> Exchanged 1000 messages in 893 millis
> Exchanged 1000 messages in 830 millis
> Exchanged 1000 messages in 676 millis
> Exchanged 1000 messages in 628 millis
> Exchanged 1000 messages in 624 millis
> Exchanged 1000 messages in 450 millis
> Exchanged 1000 messages in 447 millis
> Exchanged 1000 messages in 445 millis
> Exchanged 1000 messages in 449 millis
> Exchanged 1000 messages in 453 millis
> Exchanged 1000 messages in 395 millis
> Exchanged 1000 messages in 401 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 385 millis
> Exchanged 1000 messages in 389 millis
> Exchanged 1000 messages in 389 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 387 millis
> Exchanged 1000 messages in 387 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 386 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 386 millis
> Exchanged 1000 messages in 389 millis
> Exchanged 1000 messages in 385 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 385 millis
> Exchanged 1000 messages in 389 millis
> Exchanged 1000 messages in 388 millis
> Exchanged 1000 messages in 386 millis
> Exchanged 1000 messages in 393 millis
> Exchanged 1000 messages in 392 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 391 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 398 millis
> Exchanged 1000 messages in 394 millis
> Exchanged 1000 messages in 394 millis
> Exchanged 1000 messages in 397 millis
> Exchanged 1000 messages in 391 millis
> Exchanged 1000 messages in 395 millis
> Exchanged 1000 messages in 391 millis
> Exchanged 1000 messages in 392 millis
> Exchanged 1000 messages in 392 millis
> Exchanged 1000 messages in 391 millis
> Exchanged 1000 messages in 392 millis
> Exchanged 1000 messages in 390 millis
> Exchanged 1000 messages in 393 millis
> Exchanged 1000 messages in 390 millis
>
>
> For comparison against the same environment here are the optimized Camel
> JMS numbers:
>
>
> [ main] SpringCamelContext INFO
> Apache Camel 2.11-SNAPSHOT (CamelContext: camel) started in 0.123 seconds
> Exchanged 1000 messages in 1367 millis
> Exchanged 1000 messages in 978 millis
> Exchanged 1000 messages in 857 millis
> Exchanged 1000 messages in 740 millis
> Exchanged 1000 messages in 703 millis
> Exchanged 1000 messages in 732 millis
> Exchanged 1000 messages in 636 millis
> Exchanged 1000 messages in 497 millis
> Exchanged 1000 messages in 476 millis
> Exchanged 1000 messages in 479 millis
> Exchanged 1000 messages in 465 millis
> Exchanged 1000 messages in 437 millis
> Exchanged 1000 messages in 428 millis
> Exchanged 1000 messages in 428 millis
> Exchanged 1000 messages in 423 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 420 millis
> Exchanged 1000 messages in 417 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 415 millis
> Exchanged 1000 messages in 420 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 419 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 415 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 419 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 416 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 420 millis
> Exchanged 1000 messages in 421 millis
> Exchanged 1000 messages in 420 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 417 millis
> Exchanged 1000 messages in 424 millis
> Exchanged 1000 messages in 421 millis
> Exchanged 1000 messages in 418 millis
> Exchanged 1000 messages in 421 millis
> Exchanged 1000 messages in 419 millis
> Exchanged 1000 messages in 427 millis
> Exchanged 1000 messages in 426 millis
> Exchanged 1000 messages in 427 millis
> Exchanged 1000 messages in 429 millis
> Exchanged 1000 messages in 425 millis
> Exchanged 1000 messages in 424 millis
>
> :)
>
> On Mon, Jul 16, 2012 at 5:07 PM, Christian Müller <
> christian.mueller@gmail.com (mailto:christian.mueller@gmail.com)> wrote:
>
> > On Mon, Jul 16, 2012 at 10:04 PM, Claus Ibsen <claus.ibsen@gmail.com (mailto:claus.ibsen@gmail.com)>
> > wrote:
> >
> > > On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller
> > > <christian.mueller@gmail.com (mailto:christian.mueller@gmail.com)> wrote:
> > > > Great explanation Claus. I answered in the SI forum to make this clear
> > >
> > > for
> > > > them.
> > >
> > >
> > > Well you could match the examples a bit more. The SI sends directly
> > > from the java code to a the JMS queue.
> > > Where as in Camel its send to a direct endpoint in a Camel route, and
> > > then to the JMS queue.
> > > You could omit the Camel route, and send directly the the JMS queue,
> > > like SI does.
> > >
> >
> > This is what my sample do.
> >
> > >
> > > Also disabling JMX performance stats may make a difference, but only
> > > for really high end performance.
> > > In this example its more the TCP / remote bandwith that is the
> > > bottleneck, and the CPU cycles to calculate performance stats for JMX.
> > >
> > > Also in Camel you can disable persistent on request/reply when sending
> > > (eg replyToDeliveryPersistent=false) but SI is sending persistent as
> > > well. But as an end user you may want this in case you are okay with
> > > sending the msg as non persistent to the broker.
> > >
> > > Also SI is having 10 concurrent consumers on the consumer side. Where
> > > as Camel has 1 consumer only. But that dont matter as much as the
> > > processing is just sending back the same message.
> > >
> >
> > Yes, I tested it also with 10 consumers and came up to the same conclusion.
> >
> > >
> > > In Camel you send the message to a bean, without giving a method name.
> > > Which forces Camel to instrospect the bean on the invocation. A better
> > > solution to match SI would to use the message translator EIP
> > >
> > > <transform><simple>${body}</simple></transform>
> > >
> > > To just transform the reply to the incoming message.
> > Yes, indeed. I will make an additional test with this config and publish
> > it. My last post was not accepted on the forum...
> >
> > >
> > >
> > > > Best,
> > > > Christian
> > > >
> > > > On Mon, Jul 16, 2012 at 8:03 AM, Claus Ibsen <claus.ibsen@gmail.com (mailto:claus.ibsen@gmail.com)>
> > > wrote:
> > > >
> > > > > On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
> > > > > <christian.mueller@gmail.com (mailto:christian.mueller@gmail.com)> wrote:
> > > > > > Thanks Adam for this pointer.
> > > > > > I respond to this thread with an optimized version of the Camel
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> > route
> > > > > which
> > > > > > is about two times faster than the Spring integration solution.
> > > > >
> > > > >
> > > > > Btw the default request/reply with Camel JMS is using temporary
> > > > > queues, eg do not specify a replyTo queue name. The temporary queues
> > > > > is like exclusive, and fast.
> > > > >
> > > > > The shared queues are for clustered / and/or if the queue is used for
> > > > > other purposes/other apps etc. eg in some brokers its not
> > > > > easy/possible to create new queues on the fly etc.
> > > > >
> > > > > And the shared option was the default from the early days of the Camel
> > > > > project, and we have kept the shared as default since.
> > > > >
> > > > > Its of course documented in the JMS page. But I guess SI people don't
> > > > > read the docs
> > > > > http://camel.apache.org/jms (request/reply section)
> > > > >
> > > > > I logged a ticket to add some logging when shared queues are in use,
> > > > > so the end user may notice this more easier, than go read the JMS docs
> > > > > https://issues.apache.org/jira/browse/CAMEL-5444
> > > > >
> > > > > > Best,
> > > > > > Christian
> > > > > >
> > > > > > On Sun, Jul 15, 2012 at 4:52 AM, aedwards <adam@middleware360.com (mailto:adam@middleware360.com)>
> > > > > wrote:
> > > > > >
> > http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > View this message in context:
> > > > > > > http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
> > > > > > > Sent from the Camel Development mailing list archive at Nabble.com (http://Nabble.com).
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Claus Ibsen
> > > > > -----------------
> > > > > FuseSource
> > > > > Email: cibsen@fusesource.com (mailto:cibsen@fusesource.com)
> > > > > Web: http://fusesource.com
> > > > > Twitter: davsclaus, fusenews
> > > > > Blog: http://davsclaus.com
> > > > > Author of Camel in Action: http://www.manning.com/ibsen
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -----------------
> > > FuseSource
> > > Email: cibsen@fusesource.com (mailto:cibsen@fusesource.com)
> > > Web: http://fusesource.com
> > > Twitter: davsclaus, fusenews
> > > Blog: http://davsclaus.com
> > > Author of Camel in Action: http://www.manning.com/ibsen
> > >
> >
> >
>
>
>
>
> --
> --
> Scott England-Sullivan
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://sully6768.blogspot.com
> Twitter: sully6768
>
>
Re: fyi - SI
Posted by Scott England-Sullivan <su...@gmail.com>.
Hi All,
As a follow up to this thread, I wanted to see where SJMS stacked up
against these results. Using the tests provided that included the
optimized Camel route from Clause, I ran the same tests against the the new
SJMS component with the following result:
[ main] SpringCamelContext INFO
Apache Camel 2.11-SNAPSHOT (CamelContext: camel) started in 0.201 seconds
Exchanged 1000 messages in 1279 millis
Exchanged 1000 messages in 893 millis
Exchanged 1000 messages in 830 millis
Exchanged 1000 messages in 676 millis
Exchanged 1000 messages in 628 millis
Exchanged 1000 messages in 624 millis
Exchanged 1000 messages in 450 millis
Exchanged 1000 messages in 447 millis
Exchanged 1000 messages in 445 millis
Exchanged 1000 messages in 449 millis
Exchanged 1000 messages in 453 millis
Exchanged 1000 messages in 395 millis
Exchanged 1000 messages in 401 millis
Exchanged 1000 messages in 388 millis
Exchanged 1000 messages in 388 millis
Exchanged 1000 messages in 385 millis
Exchanged 1000 messages in 389 millis
Exchanged 1000 messages in 389 millis
Exchanged 1000 messages in 388 millis
Exchanged 1000 messages in 387 millis
Exchanged 1000 messages in 387 millis
Exchanged 1000 messages in 390 millis
Exchanged 1000 messages in 386 millis
Exchanged 1000 messages in 388 millis
Exchanged 1000 messages in 386 millis
Exchanged 1000 messages in 389 millis
Exchanged 1000 messages in 385 millis
Exchanged 1000 messages in 390 millis
Exchanged 1000 messages in 385 millis
Exchanged 1000 messages in 389 millis
Exchanged 1000 messages in 388 millis
Exchanged 1000 messages in 386 millis
Exchanged 1000 messages in 393 millis
Exchanged 1000 messages in 392 millis
Exchanged 1000 messages in 390 millis
Exchanged 1000 messages in 391 millis
Exchanged 1000 messages in 390 millis
Exchanged 1000 messages in 398 millis
Exchanged 1000 messages in 394 millis
Exchanged 1000 messages in 394 millis
Exchanged 1000 messages in 397 millis
Exchanged 1000 messages in 391 millis
Exchanged 1000 messages in 395 millis
Exchanged 1000 messages in 391 millis
Exchanged 1000 messages in 392 millis
Exchanged 1000 messages in 392 millis
Exchanged 1000 messages in 391 millis
Exchanged 1000 messages in 392 millis
Exchanged 1000 messages in 390 millis
Exchanged 1000 messages in 393 millis
Exchanged 1000 messages in 390 millis
For comparison against the same environment here are the optimized Camel
JMS numbers:
[ main] SpringCamelContext INFO
Apache Camel 2.11-SNAPSHOT (CamelContext: camel) started in 0.123 seconds
Exchanged 1000 messages in 1367 millis
Exchanged 1000 messages in 978 millis
Exchanged 1000 messages in 857 millis
Exchanged 1000 messages in 740 millis
Exchanged 1000 messages in 703 millis
Exchanged 1000 messages in 732 millis
Exchanged 1000 messages in 636 millis
Exchanged 1000 messages in 497 millis
Exchanged 1000 messages in 476 millis
Exchanged 1000 messages in 479 millis
Exchanged 1000 messages in 465 millis
Exchanged 1000 messages in 437 millis
Exchanged 1000 messages in 428 millis
Exchanged 1000 messages in 428 millis
Exchanged 1000 messages in 423 millis
Exchanged 1000 messages in 416 millis
Exchanged 1000 messages in 420 millis
Exchanged 1000 messages in 417 millis
Exchanged 1000 messages in 416 millis
Exchanged 1000 messages in 415 millis
Exchanged 1000 messages in 420 millis
Exchanged 1000 messages in 418 millis
Exchanged 1000 messages in 418 millis
Exchanged 1000 messages in 419 millis
Exchanged 1000 messages in 416 millis
Exchanged 1000 messages in 415 millis
Exchanged 1000 messages in 416 millis
Exchanged 1000 messages in 419 millis
Exchanged 1000 messages in 418 millis
Exchanged 1000 messages in 416 millis
Exchanged 1000 messages in 418 millis
Exchanged 1000 messages in 420 millis
Exchanged 1000 messages in 421 millis
Exchanged 1000 messages in 420 millis
Exchanged 1000 messages in 418 millis
Exchanged 1000 messages in 417 millis
Exchanged 1000 messages in 424 millis
Exchanged 1000 messages in 421 millis
Exchanged 1000 messages in 418 millis
Exchanged 1000 messages in 421 millis
Exchanged 1000 messages in 419 millis
Exchanged 1000 messages in 427 millis
Exchanged 1000 messages in 426 millis
Exchanged 1000 messages in 427 millis
Exchanged 1000 messages in 429 millis
Exchanged 1000 messages in 425 millis
Exchanged 1000 messages in 424 millis
:)
On Mon, Jul 16, 2012 at 5:07 PM, Christian Müller <
christian.mueller@gmail.com> wrote:
> On Mon, Jul 16, 2012 at 10:04 PM, Claus Ibsen <cl...@gmail.com>
> wrote:
>
> > On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller
> > <ch...@gmail.com> wrote:
> > > Great explanation Claus. I answered in the SI forum to make this clear
> > for
> > > them.
> > >
> >
> > Well you could match the examples a bit more. The SI sends directly
> > from the java code to a the JMS queue.
> > Where as in Camel its send to a direct endpoint in a Camel route, and
> > then to the JMS queue.
> > You could omit the Camel route, and send directly the the JMS queue,
> > like SI does.
> >
> This is what my sample do.
>
> >
> > Also disabling JMX performance stats may make a difference, but only
> > for really high end performance.
> > In this example its more the TCP / remote bandwith that is the
> > bottleneck, and the CPU cycles to calculate performance stats for JMX.
> >
> > Also in Camel you can disable persistent on request/reply when sending
> > (eg replyToDeliveryPersistent=false) but SI is sending persistent as
> > well. But as an end user you may want this in case you are okay with
> > sending the msg as non persistent to the broker.
> >
> > Also SI is having 10 concurrent consumers on the consumer side. Where
> > as Camel has 1 consumer only. But that dont matter as much as the
> > processing is just sending back the same message.
> >
> Yes, I tested it also with 10 consumers and came up to the same conclusion.
>
> >
> > In Camel you send the message to a bean, without giving a method name.
> > Which forces Camel to instrospect the bean on the invocation. A better
> > solution to match SI would to use the message translator EIP
> >
> > <transform><simple>${body}</simple></transform>
> >
> > To just transform the reply to the incoming message.
> >
> Yes, indeed. I will make an additional test with this config and publish
> it. My last post was not accepted on the forum...
>
> >
> >
> > > Best,
> > > Christian
> > >
> > > On Mon, Jul 16, 2012 at 8:03 AM, Claus Ibsen <cl...@gmail.com>
> > wrote:
> > >
> > >> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
> > >> <ch...@gmail.com> wrote:
> > >> > Thanks Adam for this pointer.
> > >> > I respond to this thread with an optimized version of the Camel
> route
> > >> which
> > >> > is about two times faster than the Spring integration solution.
> > >> >
> > >>
> > >> Btw the default request/reply with Camel JMS is using temporary
> > >> queues, eg do not specify a replyTo queue name. The temporary queues
> > >> is like exclusive, and fast.
> > >>
> > >> The shared queues are for clustered / and/or if the queue is used for
> > >> other purposes/other apps etc. eg in some brokers its not
> > >> easy/possible to create new queues on the fly etc.
> > >>
> > >> And the shared option was the default from the early days of the Camel
> > >> project, and we have kept the shared as default since.
> > >>
> > >> Its of course documented in the JMS page. But I guess SI people don't
> > >> read the docs
> > >> http://camel.apache.org/jms (request/reply section)
> > >>
> > >> I logged a ticket to add some logging when shared queues are in use,
> > >> so the end user may notice this more easier, than go read the JMS docs
> > >> https://issues.apache.org/jira/browse/CAMEL-5444
> > >>
> > >> > Best,
> > >> > Christian
> > >> >
> > >> > On Sun, Jul 15, 2012 at 4:52 AM, aedwards <ad...@middleware360.com>
> > >> wrote:
> > >> >
> > >> >>
> > >> >>
> > >>
> >
> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
> > >> >>
> > >> >>
> > >> >> --
> > >> >> View this message in context:
> > >> >> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
> > >> >> Sent from the Camel Development mailing list archive at Nabble.com.
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >> Claus Ibsen
> > >> -----------------
> > >> FuseSource
> > >> Email: cibsen@fusesource.com
> > >> Web: http://fusesource.com
> > >> Twitter: davsclaus, fusenews
> > >> Blog: http://davsclaus.com
> > >> Author of Camel in Action: http://www.manning.com/ibsen
> > >>
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > FuseSource
> > Email: cibsen@fusesource.com
> > Web: http://fusesource.com
> > Twitter: davsclaus, fusenews
> > Blog: http://davsclaus.com
> > Author of Camel in Action: http://www.manning.com/ibsen
> >
>
--
--
Scott England-Sullivan
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://sully6768.blogspot.com
Twitter: sully6768
Re: fyi - SI
Posted by Christian Müller <ch...@gmail.com>.
On Mon, Jul 16, 2012 at 10:04 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller
> <ch...@gmail.com> wrote:
> > Great explanation Claus. I answered in the SI forum to make this clear
> for
> > them.
> >
>
> Well you could match the examples a bit more. The SI sends directly
> from the java code to a the JMS queue.
> Where as in Camel its send to a direct endpoint in a Camel route, and
> then to the JMS queue.
> You could omit the Camel route, and send directly the the JMS queue,
> like SI does.
>
This is what my sample do.
>
> Also disabling JMX performance stats may make a difference, but only
> for really high end performance.
> In this example its more the TCP / remote bandwith that is the
> bottleneck, and the CPU cycles to calculate performance stats for JMX.
>
> Also in Camel you can disable persistent on request/reply when sending
> (eg replyToDeliveryPersistent=false) but SI is sending persistent as
> well. But as an end user you may want this in case you are okay with
> sending the msg as non persistent to the broker.
>
> Also SI is having 10 concurrent consumers on the consumer side. Where
> as Camel has 1 consumer only. But that dont matter as much as the
> processing is just sending back the same message.
>
Yes, I tested it also with 10 consumers and came up to the same conclusion.
>
> In Camel you send the message to a bean, without giving a method name.
> Which forces Camel to instrospect the bean on the invocation. A better
> solution to match SI would to use the message translator EIP
>
> <transform><simple>${body}</simple></transform>
>
> To just transform the reply to the incoming message.
>
Yes, indeed. I will make an additional test with this config and publish
it. My last post was not accepted on the forum...
>
>
> > Best,
> > Christian
> >
> > On Mon, Jul 16, 2012 at 8:03 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
> >
> >> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
> >> <ch...@gmail.com> wrote:
> >> > Thanks Adam for this pointer.
> >> > I respond to this thread with an optimized version of the Camel route
> >> which
> >> > is about two times faster than the Spring integration solution.
> >> >
> >>
> >> Btw the default request/reply with Camel JMS is using temporary
> >> queues, eg do not specify a replyTo queue name. The temporary queues
> >> is like exclusive, and fast.
> >>
> >> The shared queues are for clustered / and/or if the queue is used for
> >> other purposes/other apps etc. eg in some brokers its not
> >> easy/possible to create new queues on the fly etc.
> >>
> >> And the shared option was the default from the early days of the Camel
> >> project, and we have kept the shared as default since.
> >>
> >> Its of course documented in the JMS page. But I guess SI people don't
> >> read the docs
> >> http://camel.apache.org/jms (request/reply section)
> >>
> >> I logged a ticket to add some logging when shared queues are in use,
> >> so the end user may notice this more easier, than go read the JMS docs
> >> https://issues.apache.org/jira/browse/CAMEL-5444
> >>
> >> > Best,
> >> > Christian
> >> >
> >> > On Sun, Jul 15, 2012 at 4:52 AM, aedwards <ad...@middleware360.com>
> >> wrote:
> >> >
> >> >>
> >> >>
> >>
> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
> >> >>
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
> >> >> Sent from the Camel Development mailing list archive at Nabble.com.
> >> >>
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> FuseSource
> >> Email: cibsen@fusesource.com
> >> Web: http://fusesource.com
> >> Twitter: davsclaus, fusenews
> >> Blog: http://davsclaus.com
> >> Author of Camel in Action: http://www.manning.com/ibsen
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: fyi - SI
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller
<ch...@gmail.com> wrote:
> Great explanation Claus. I answered in the SI forum to make this clear for
> them.
>
Well you could match the examples a bit more. The SI sends directly
from the java code to a the JMS queue.
Where as in Camel its send to a direct endpoint in a Camel route, and
then to the JMS queue.
You could omit the Camel route, and send directly the the JMS queue,
like SI does.
Also disabling JMX performance stats may make a difference, but only
for really high end performance.
In this example its more the TCP / remote bandwith that is the
bottleneck, and the CPU cycles to calculate performance stats for JMX.
Also in Camel you can disable persistent on request/reply when sending
(eg replyToDeliveryPersistent=false) but SI is sending persistent as
well. But as an end user you may want this in case you are okay with
sending the msg as non persistent to the broker.
Also SI is having 10 concurrent consumers on the consumer side. Where
as Camel has 1 consumer only. But that dont matter as much as the
processing is just sending back the same message.
In Camel you send the message to a bean, without giving a method name.
Which forces Camel to instrospect the bean on the invocation. A better
solution to match SI would to use the message translator EIP
<transform><simple>${body}</simple></transform>
To just transform the reply to the incoming message.
> Best,
> Christian
>
> On Mon, Jul 16, 2012 at 8:03 AM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
>> <ch...@gmail.com> wrote:
>> > Thanks Adam for this pointer.
>> > I respond to this thread with an optimized version of the Camel route
>> which
>> > is about two times faster than the Spring integration solution.
>> >
>>
>> Btw the default request/reply with Camel JMS is using temporary
>> queues, eg do not specify a replyTo queue name. The temporary queues
>> is like exclusive, and fast.
>>
>> The shared queues are for clustered / and/or if the queue is used for
>> other purposes/other apps etc. eg in some brokers its not
>> easy/possible to create new queues on the fly etc.
>>
>> And the shared option was the default from the early days of the Camel
>> project, and we have kept the shared as default since.
>>
>> Its of course documented in the JMS page. But I guess SI people don't
>> read the docs
>> http://camel.apache.org/jms (request/reply section)
>>
>> I logged a ticket to add some logging when shared queues are in use,
>> so the end user may notice this more easier, than go read the JMS docs
>> https://issues.apache.org/jira/browse/CAMEL-5444
>>
>> > Best,
>> > Christian
>> >
>> > On Sun, Jul 15, 2012 at 4:52 AM, aedwards <ad...@middleware360.com>
>> wrote:
>> >
>> >>
>> >>
>> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
>> >> Sent from the Camel Development mailing list archive at Nabble.com.
>> >>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: fyi - SI
Posted by Christian Müller <ch...@gmail.com>.
Great explanation Claus. I answered in the SI forum to make this clear for
them.
Best,
Christian
On Mon, Jul 16, 2012 at 8:03 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
> <ch...@gmail.com> wrote:
> > Thanks Adam for this pointer.
> > I respond to this thread with an optimized version of the Camel route
> which
> > is about two times faster than the Spring integration solution.
> >
>
> Btw the default request/reply with Camel JMS is using temporary
> queues, eg do not specify a replyTo queue name. The temporary queues
> is like exclusive, and fast.
>
> The shared queues are for clustered / and/or if the queue is used for
> other purposes/other apps etc. eg in some brokers its not
> easy/possible to create new queues on the fly etc.
>
> And the shared option was the default from the early days of the Camel
> project, and we have kept the shared as default since.
>
> Its of course documented in the JMS page. But I guess SI people don't
> read the docs
> http://camel.apache.org/jms (request/reply section)
>
> I logged a ticket to add some logging when shared queues are in use,
> so the end user may notice this more easier, than go read the JMS docs
> https://issues.apache.org/jira/browse/CAMEL-5444
>
> > Best,
> > Christian
> >
> > On Sun, Jul 15, 2012 at 4:52 AM, aedwards <ad...@middleware360.com>
> wrote:
> >
> >>
> >>
> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
> >>
> >>
> >> --
> >> View this message in context:
> >> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
> >> Sent from the Camel Development mailing list archive at Nabble.com.
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: fyi - SI
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
<ch...@gmail.com> wrote:
> Thanks Adam for this pointer.
> I respond to this thread with an optimized version of the Camel route which
> is about two times faster than the Spring integration solution.
>
Btw the default request/reply with Camel JMS is using temporary
queues, eg do not specify a replyTo queue name. The temporary queues
is like exclusive, and fast.
The shared queues are for clustered / and/or if the queue is used for
other purposes/other apps etc. eg in some brokers its not
easy/possible to create new queues on the fly etc.
And the shared option was the default from the early days of the Camel
project, and we have kept the shared as default since.
Its of course documented in the JMS page. But I guess SI people don't
read the docs
http://camel.apache.org/jms (request/reply section)
I logged a ticket to add some logging when shared queues are in use,
so the end user may notice this more easier, than go read the JMS docs
https://issues.apache.org/jira/browse/CAMEL-5444
> Best,
> Christian
>
> On Sun, Jul 15, 2012 at 4:52 AM, aedwards <ad...@middleware360.com> wrote:
>
>>
>> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: fyi - SI
Posted by Christian Müller <ch...@gmail.com>.
Thanks Adam for this pointer.
I respond to this thread with an optimized version of the Camel route which
is about two times faster than the Spring integration solution.
Best,
Christian
On Sun, Jul 15, 2012 at 4:52 AM, aedwards <ad...@middleware360.com> wrote:
>
> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
Re: fyi - SI
Posted by Babak Vahdat <ba...@swissonline.ch>.
Very well done! Kudos :-)
Babak
Claus Ibsen-2 wrote
>
> Hi
>
> On Sun, Jul 15, 2012 at 4:52 AM, aedwards <adam@> wrote:
>> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
>>
>
> A memory leak has been discovered in the AMQ 5.6.0 connection pool
> (activemq-pool). This is why the above test could not complete using
> the AMQ pooling. But could complete with the Spring based pooling
> instead.
>
> I have tracked down the leak and logged a ticket in AMQ
> https://issues.apache.org/jira/browse/AMQ-3997
>
> With a fix in place, the test can complete with activemq-pool without
> any memory leaks or issues.
> The performance numbers is on par with the spring based pooling.
>
>
>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
--
View this message in context: http://camel.465427.n5.nabble.com/fyi-SI-tp5716049p5718191.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: fyi - SI
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
On Sun, Jul 15, 2012 at 4:52 AM, aedwards <ad...@middleware360.com> wrote:
> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
>
A memory leak has been discovered in the AMQ 5.6.0 connection pool
(activemq-pool). This is why the above test could not complete using
the AMQ pooling. But could complete with the Spring based pooling
instead.
I have tracked down the leak and logged a ticket in AMQ
https://issues.apache.org/jira/browse/AMQ-3997
With a fix in place, the test can complete with activemq-pool without
any memory leaks or issues.
The performance numbers is on par with the spring based pooling.
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen