I like these numbers...
Christian
Sent from a mobile device
Am 06.08.2012 08:06 schrieb "Scott England-Sullivan" <sully6...@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.muel...@gmail.com> wrote:
>
> > On Mon, Jul 16, 2012 at 10:04 PM, Claus Ibsen <claus.ib...@gmail.com>
> > wrote:
> >
> > > On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller
> > > <christian.muel...@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.ib...@gmail.com>
> > > wrote:
> > > >
> > > >> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
> > > >> <christian.muel...@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 <a...@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: cib...@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: cib...@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
>
