fyi - SI
Locked
 
|
Re: fyi - SI
|
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 <[hidden email]> 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: [hidden email] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen |
Re: fyi - SI
|
In reply to this post by aedwards
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 <[hidden email]> 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
|
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 <[hidden email]> 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
|
|
In reply to this post by Christian Mueller
On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
<[hidden email]> 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 <[hidden email]> 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: [hidden email] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen |
Re: fyi - SI
|
|
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 <[hidden email]> wrote: > On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller > <[hidden email]> 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 <[hidden email]> > 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: [hidden email] > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > |
Re: fyi - SI
|
|
On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller
<[hidden email]> 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 <[hidden email]> wrote: > >> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller >> <[hidden email]> 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 <[hidden email]> >> 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: [hidden email] >> 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: [hidden email] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen |
Re: fyi - SI
|
|
On Mon, Jul 16, 2012 at 10:04 PM, Claus Ibsen <[hidden email]> wrote:
> On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller > <[hidden email]> 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. > 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 <[hidden email]> > wrote: > > > >> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller > >> <[hidden email]> 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 <[hidden email]> > >> 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: [hidden email] > >> 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: [hidden email] > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > |
|
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 < [hidden email]> wrote: > On Mon, Jul 16, 2012 at 10:04 PM, Claus Ibsen <[hidden email]> > wrote: > > > On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller > > <[hidden email]> 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 <[hidden email]> > > wrote: > > > > > >> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller > > >> <[hidden email]> 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 <[hidden email]> > > >> 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: [hidden email] > > >> 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: [hidden email] > > 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
--
Scott England-Sullivan ---------------------------------- FuseSource Web: http://www.fusesource.com Blog: http://sully6768.blogspot.com Twitter: sully6768 |
Re: fyi - SI
|
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 < > [hidden email] (mailto:[hidden email])> wrote: > > > On Mon, Jul 16, 2012 at 10:04 PM, Claus Ibsen <[hidden email] (mailto:[hidden email])> > > wrote: > > > > > On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller > > > <[hidden email] (mailto:[hidden email])> 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 <[hidden email] (mailto:[hidden email])> > > > wrote: > > > > > > > > > On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller > > > > > <[hidden email] (mailto:[hidden email])> 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 <[hidden email] (mailto:[hidden email])> > > > > > 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: [hidden email] (mailto:[hidden email]) > > > > > 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: [hidden email] (mailto:[hidden email]) > > > 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
|
|
In reply to this post by sully6768
I like these numbers...
Christian Sent from a mobile device Am 06.08.2012 08:06 schrieb "Scott England-Sullivan" <[hidden email]>: > 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 < > [hidden email]> wrote: > > > On Mon, Jul 16, 2012 at 10:04 PM, Claus Ibsen <[hidden email]> > > wrote: > > > > > On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller > > > <[hidden email]> 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 <[hidden email]> > > > wrote: > > > > > > > >> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller > > > >> <[hidden email]> 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 <[hidden email] > > > > > >> 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: [hidden email] > > > >> 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: [hidden email] > > > 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
|
|
In reply to this post by aedwards
Hi
On Sun, Jul 15, 2012 at 4:52 AM, aedwards <[hidden email]> 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: [hidden email] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen |
Re: fyi - SI
|
Very well done! Kudos :-)
Babak
|
«
Return to Camel Development
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |