activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: Setting expireMessagesPeriod=0 for advisory topics improved GC performance by 2x..
Date Mon, 04 May 2015 05:11:00 GMT
Kevin,

Messages don't pile up on advisory topics because of the semantics of
topics: unless you have a durable subscription (which the broker-to-broker
advisory subscriptions aren't, if I recall correctly), any message that
arrives on the broker will be delivered to all connected consumers (and not
to any disconnected ones), so the only thing that could cause messages to
back up is a slow consumer (which I've never observed to happen, though I'm
sure it's possible).  You could certainly get slow consumers and/or durable
subscriptions on advisory topics if you've written custom consumers, just
like for any other topic, but that's a separate issue.

I wasn't at all clear why changing the frequency (to "never") of message
expiration checks would affect the performance of destination GC operations
when the number of queues is large.  Is that due to synchronization between
those two operations, or thread contention because one or both takes longer
than its periodicity to complete so we eventually have more pending threads
than the cores can run, or...  I'm in favor of the changes as you've
described it (I can't think of a reason we'd want advisory messages to
expire, though ideally it would be configurable for just in case someone
has a need for it that I can't think of; configurable or not, having 0 as
the default sounds like a clear win to me), I'm just not clear on how it
has the larger effects you describe.

Also, can you point me to the O(N^2) code related to Timer.purge()?  If it
really is purging every queue each time any queue's timer fires, that
sounds like incorrect code, but I'd like to see it to make sure I'm not
misunderstanding what you're describing.

Tim
On May 2, 2015 4:34 PM, "Kevin Burton" <burton@spinn3r.com> wrote:

> I’m confused by something.  Why don’t messages pile up in advisory topics?
> Topics only deliver messages to consumers who are actually listening I
> assume?
>
> On Sat, May 2, 2015 at 2:07 PM, Kevin Burton <burton@spinn3r.com> wrote:
>
> > I’m sorry.. this is N^2 because the Timer just keeps growing for every
> new
> > queue and they need to be purged and it has to evaluate each one.
> >
> > On Sat, May 2, 2015 at 1:40 PM, Kevin Burton <burton@spinn3r.com> wrote:
> >
> >> Also, while this is a small performance boost in my example, this should
> >> have a massive impact when running with large queues.  It’s calling
> >> Timer.purge() on each queue GC and if you have a lot of queues you’re
> going
> >> to have a lot of TimerTasks so this is a O(N).  It also holds a global
> lock
> >> during this operation so no new queues can be created during a queue GC.
> >>
> >> On Sat, May 2, 2015 at 12:23 PM, Kevin Burton <burton@spinn3r.com>
> wrote:
> >>
> >>> I’m doing a bunch of performance analysis of ActiveMQ this weekend to
> >>> see if I can improve queue creation and destruction time.  The good
> news is
> >>> that there are a lot of areas of optimization.
> >>>
> >>> It looks like one is that advisory topics are created with the default
> >>> expireMessagesPeriod (which is 30000). However, no advisory messages
> are
> >>> produced with TTLs.
> >>>
> >>> I believe this is done in AdvisoryBroker.fireAdvisory
> >>>
> >>> … looking at this code, a TTL isn’t set.  So I think that it would be
a
> >>> good idea to enable expireMessagesPeriod=0 for advisory topics.
> >>>
> >>> Here’s the code if you’re interested:
> >>>
> >>> http://pastebin.com/i3hXDGEW
> >>>
> >>> Looks like the following policyEntry works as a proof of concept.
> >>>
> >>>                     <policyEntry topic=">"
> >>>                                  prioritizedMessages="false"
> >>>                                  useCache="false"
> >>>                                  maxBrowsePageSize="2147483647"
> >>>                                  expireMessagesPeriod="0">
> >>>
> >>>                     </policyEntry>
> >>>
> >>> (I am going to constrain it for advisory topics though).
> >>>
> >>> In my test time time for GCing all my queues went from 45s to 17s.
> It’s
> >>> MUCH higher than this under production load though due threading
> issues.
> >>>
> >>> Are there any potential issues I might be missing here?
> >>>
> >>> If this works I might try to submit a patch to disable
> >>> expireMessagesPeriod by default for advisory topics.
> >>>
> >>> --
> >>>
> >>> Founder/CEO Spinn3r.com
> >>> Location: *San Francisco, CA*
> >>> blog: http://burtonator.wordpress.com
> >>> … or check out my Google+ profile
> >>> <https://plus.google.com/102718274791889610666/posts>
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Founder/CEO Spinn3r.com
> >> Location: *San Francisco, CA*
> >> blog: http://burtonator.wordpress.com
> >> … or check out my Google+ profile
> >> <https://plus.google.com/102718274791889610666/posts>
> >>
> >>
> >
> >
> > --
> >
> > Founder/CEO Spinn3r.com
> > Location: *San Francisco, CA*
> > blog: http://burtonator.wordpress.com
> > … or check out my Google+ profile
> > <https://plus.google.com/102718274791889610666/posts>
> >
> >
>
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>
>

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