qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Experiences with Qpid AMQP 1.0 JMS client in production
Date Tue, 26 Aug 2014 14:58:39 GMT
So, first thing to make sure would be to make sure either both clients are
in synchronous publish mode, or both in async...  it makes a *huge*
difference. (To turn off synchronous publish on the 1.0 client you can
either set the system property "qpid.sync_publish" to false, or add the
connection url argument sync-publish=false).

We'd also need to look at how much of any performance difference is down to
the client and how much to the broker... I see Gordon has already replied
saying that he's made changes broker side on the performance of the C++
broker...  I think it's probably also true that the Java Broker performance
for 1.0 will  be lower simply because we've not spent the time tuning it
yet.  Hopefully once we've got a few scenarios like yours we can start to
look at tuning for the use-cases our users care about.

Cheers,
Rob


On 26 August 2014 16:50, Adams, Cory <coadams@paypal.com.invalid> wrote:

> Hi Rob,
>
> I will pickup the test scenario later today and provide details.  We were
> doing simple bulk message sending to a queue with an asynch listener and
> then comparing that to the throughput using the swiftmq driver.  This was
> against the qpid c++ broker.
>
> Thank you,
>
> Cory
>
> -----Original Message-----
> From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> Sent: Tuesday, August 26, 2014 9:40 AM
> To: users@qpid.apache.org
> Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
>
> Hi Cory,
>
> On 26 August 2014 16:25, Adams, Cory <coadams@paypal.com.invalid> wrote:
>
> > Hi Rob,
> >
> > We are considering the JMS AMQP 1.0 client to be of high importance
> > and central to the success of our project.  We have found that the
> > Qpid jms amqp 1.0 was indeed slow from a performance perspective.
> >
> >
> Can you give some details on the slowness - both the observed performance
> and the usage pattern.  As I think Robbie pointed out in the other thread
> it's important to make sure that we are comparing like with like (for
> instance by default the JMS 1.0 client uses synchronous publishing, whereas
> the 0-x client publishes asynchronously... the former will always be a
> *lot* slower than the latter, but each client can be configured to use
> either mode - arguably the 1.0 client is correctly implementing the JMS
> spec by default, whereas the 0.x client is playing a bit fast and loose :-)
> ).
>
> In general I might expect the JMS 1.0 client to be slower because we've
> really not tuned it yet... but not orders of magnitude slower... and in
> persistent  messaging the client should not be the critical path.
>
> Is there a timeline for shifting work toward the jms amqp 1.0
> > implementation on Proton?
> >
> >
> Robbie Gemmell is leading the work on the the new client - he would be in
> a better position to give dates.
>
> Hope that helps,
> Rob
>
> Thank you,
> >
> > Cory
> >
> > -----Original Message-----
> > From: Rob Godfrey [mailto:rob.j.godfrey@gmail.com]
> > Sent: Tuesday, August 26, 2014 3:40 AM
> > To: users@qpid.apache.org
> > Subject: Re: Experiences with Qpid AMQP 1.0 JMS client in production
> >
> > Hi Erik,
> >
> > I'm pretty sure there are people using the JMS 1.0 client in
> > production, as it is the client that Microsoft points users of their
> > Azure Service Bus offering to if they want to connect using Java
> > applications.  I'm not sure how many of these users are subscribed to
> this list however.
> >
> > In terms of the client itself, it's obviously less mature than the
> > 0-8/9/-9-1/-10 client (though almost definitionally it's as mature as
> > that client was when that client was the same age :-) ), and doesn't
> > have some of the features that the older client does (such as
> > automatic failover support).  Moreover the JMS AMQP 1.0 client was
> > written before the Proton effort at a single AMQP 1.0 protocol engine
> > was started - and as a result we are aiming to eventually replace the
> > current JMS 1.0 client with one that is built around Proton so that
> > overall our AMQP 1.0 effort is easier to maintain (Robbie Gemmell is
> > leading this) . Until that work is completed we'll still try to
> > address any issues that arise (there are a number of fixes for the JMS
> > 1.0 client in the upcoming 0.30 release), and also look at introducing
> > new features where they are in line with the work on the standardised
> > JMS mapping to AMQP that is going on at OASIS.  By keeping to standard
> > JMS and the OASIS mapping there should be minimal impact in moving
> > from the current JMS AMQP 1.0 client to the one based on Proton when it
> arrives.
> >
> > As was mentioned in another thread, the JMS AMQP 1.0 client has
> > certainly not been tuned for performance, so if you are looking to
> > send millions of message per second or guarantee nanosecond latency,
> > then it may not be for you.  Overall all I can really say is that you
> > should test it to see if it meets your particular functional and
> non-functional requirements.
> >
> > Hope this helps,
> > Rob
> >
> >
> > On 26 August 2014 08:17, Erik Aschenbrenner <easchenb@icubic.de> wrote:
> >
> > > Dear Qpid users,
> > >
> > > so nobody has experiences with Qpid AMQP 1.0 JMS client in
> > > production so far?
> > >
> > > Regards,
> > > Erik
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > > http://qpid.2158936.n2.nabble.com/Experiences-with-Qpid-AMQP-1-0-JMS
> > > -c lient-in-production-tp7611393p7612537.html
> > > Sent from the Apache Qpid users mailing list archive at Nabble.com.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message