[
https://issues.apache.org/jira/browse/AMQ-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437571#comment-17437571
]
Josh Byster commented on AMQ-5824:
----------------------------------
Hello! Thanks for reporting this ticket. We're noticing that we're running into
this issue as well, and it has become increasingly difficult to work around. We
have found that this operation is on the order of O(n^2) when a connection has
many subscriptions/consumers. This causes us to take about 75% of CPU time just
reserved for removing consumers.
More precisely, removing 1 connection requires approximately an iteration count
of (number of consumers per connection * total number of consumers for the
broker).
For example, if the broker has 1 million total consumers, and a single
connection is removed that has 1000 consumers, there are about 1 billion
operations that must take place to remove that single consumer.
> Improve performance of ManagedRegionBroker.removeConsumer()
> -----------------------------------------------------------
>
> Key: AMQ-5824
> URL: https://issues.apache.org/jira/browse/AMQ-5824
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.11.1
> Reporter: Tim Bain
> Priority: Minor
> Labels: performance
>
> In a Users mailing list post
> (http://activemq.2283324.n4.nabble.com/More-ActiveMQ-hotspots-courtesy-of-continuous-profiling-td4697159.html),
> Kevin Burton noticed that ManagedRegionBroker.removeConsumer() was taking
> 50% of his CPU cycles because we're iterating through all subscriptions
> looking for ones that match a given ConsumerInfo. His scenario's a little
> unique because he uses far more destinations (and far more consumers) than
> most installations, but it still highlighted a potential performance
> improvement.
> He proposed that we keep a Map<ConsumerInfo, Subscription> (does it need to
> be a Multimap?) in addition to the Map<Subscription, ObjectName> so we can
> quickly find the Subscription or Subscriptions for the given ConsumerInfo.
> Note that even using a concurrent collection won't synchronize between the
> two nor synchronize with logic that tests the existence of an element in the
> collection and then acts accordingly. subscriptionMap already has this
> problem, so simply using a concurrent Map/Multimap without doing additional
> synchronization may not make it worse, but we really should evaluate whether
> we need explicit synchronization rather than relying on the concurrent
> collection as the sole means of synchronization.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
