activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Gomes" <e.se...@gmail.com>
Subject Re: Optimising PrefetchSubscription.dispatchPending() ideas
Date Thu, 14 Feb 2008 18:12:44 GMT
That's great!  I would definitely like to see Topics improved, because my
testing shows that they are significantly slower than Queues.  Here are some
rough statistics that I have gathered so far.  I have more detailed data,
but this should give an idea of what I'm seeing.

*Scenario:*

   - Network bandwidth is 1 Gigabit LAN.
   - NMS OpenWire Producer on Machine A, sending 500,000 simple text
   messages using sendAsync=true.
   - ActiveMQ Broker on Machine B.
   - Four NMS OpenWire Consumers on Topic on Machine C.  One NMS OpenWire
   Consumer on Queue on Machine C.


*Results:*

   - The Queue message/second send rate is around 5,900.
   - The Topic message/second send rate is around 360.


This is a huge difference owing to the fact that ActiveMQ is slowing down
the Producer, even though it is sending asynchronously.  Sending to a topic
that has Consumers (none of them idle) is 16 times slower than sending to a
Queue that has a Consumer.

If I remove all Consumers on Machine C, then the Queue message/second send
rate jumps to 9,300, and the Topic message/second send rate goes to 7,700.
For whatever reasons, Topics are inherently slower than Queues.

I'll use this test scenario to measure any changes in performance.  If
anyone has suggestions on how to tune the broker, producers, or consumers to
get better speed, please let me know.

Regards,
Jim

On Wed, Feb 13, 2008 at 11:35 PM, Rob Davies <rajdavies@gmail.com> wrote:

>
> On Feb 14, 2008, at 3:08 AM, David Sitsky wrote:
>
> > Rob and I did some performance enhancements with queues so that a
> > Queue.send() call was decoupled from the dispatch processing.  In
> > the past, depending on the state of the consumers, a Queue.send()
> > call could take a significant amount of time.  We changed it so that
> > a single thread was responsible for dispatching messages, which
> > avoided a lot of lock contention.  It also meant a Queue.send()
> > returned as quickly as possible.
> >
> > I imagine a similar change could be done for Topics, since from what
> > I can tell, a Topic.send() call currently does its dispatch
> > processing in the same call.
> >
> > Cheers,
> > David
> >
> > Jim Gomes wrote:
> >> I am very interested in this set of changes.  I am currently
> >> load/performance testing ActiveMQ, and am very surprised at the
> >> results.
> >> Anything that can be done to speed this area is a good thing.  I
> >> have found
> >> a dramatic drop in performance when adding even a single consumer,
> >> especially to a Topic.  The producer to the Topic is slowed down
> >> quite a
> >> bit, which was a surprise to me.  I expected that the
> >> existence/non-existence or performance of a consumer would have no
> >> impact on
> >> a producer, but that is not the case.  A producer is directly
> >> impacted by
> >> any consumers, especially idle consumers.  An idle Topic consumer can
> >> actually cause a producer to block.  As far as I have been able to
> >> determine
> >> from browsing the documentation, this is by design.
> >> I am looking forward to your efforts in this area.
> >> Best Regards,
> >> Jim
> >
> > --
> > Cheers,
> > David
> >
> > Nuix Pty Ltd
> > Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280
> > 0699
> > Web: http://www.nuix.com                            Fax: +61 2 9212
> > 6902
>
>
> Yes - Topics next!
>
> cheers,
>
> Rob
>

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