[ 
https://issues.apache.org/jira/browse/ARTEMIS-2399?focusedWorklogId=277916&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-277916
 ]

ASF GitHub Bot logged work on ARTEMIS-2399:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 17/Jul/19 01:30
            Start Date: 17/Jul/19 01:30
    Worklog Time Spent: 10m 
      Work Description: wy96f commented on pull request #2750: ARTEMIS-2399 
Improve performance when there are a lot of subscribers
URL: https://github.com/apache/activemq-artemis/pull/2750#discussion_r304187715
 
 

 ##########
 File path: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
 ##########
 @@ -324,13 +325,7 @@ public String debug() {
          out.println("consumer: " + holder.consumer.debug());
       }
 
-      for (MessageReference reference : intermediateMessageReferences) {
-         out.print("Intermediate reference:" + reference);
-      }
-
-      if (intermediateMessageReferences.isEmpty()) {
-         out.println("No intermediate references");
-      }
+      out.println("Intermediate reference size is " + 
intermediateMessageReferences.size());
 
 Review comment:
   MpscUnboundedArrayQueue might perform well in journal mode where there are 
many producers and one consumer. The main reason I used MpscUnboundedArrayQueue 
is I need to calculate size of messages both in intermediateMessageReferences 
and messageReferences, i.e.`intermediateMessageReferences.size() + 
messageReferences.size() < MAX_DEPAGE_NUM` in QueueImpl::needsDepage. However 
time complexity of size() for ConcurrentLinkedQueue is O(n), so I replaced it 
with MpscUnboundedArrayQueue(I did't find other queues fit for our scenario). I 
didn't think about issues like kafraf, debug by introducing this.
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 277916)
    Time Spent: 11h 50m  (was: 11h 40m)

> Improve performance when there are a lot of subscribers
> -------------------------------------------------------
>
>                 Key: ARTEMIS-2399
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2399
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>          Components: Broker
>    Affects Versions: 2.9.0
>         Environment: broker 2.9.0
> cpu: 4 cores, memory: 8G, disk: ssd 500G
> broker.xml:
>          <thread-pool-max-size>60</thread-pool-max-size>
>         <address-setting match="#">
>                  <max-size-bytes>51Mb</max-size-bytes>
>                  <page-size-bytes>50Mb</page-size-bytes>
>                  <page-max-cache-size>1</page-max-cache-size>
>                  <address-full-policy>PAGE</address-full-policy>
>         </address-setting> 
>          <message-expiry-scan-period>-1</message-expiry-scan-period>    
>            Reporter: yangwei
>            Priority: Major
>          Time Spent: 11h 50m
>  Remaining Estimate: 0h
>
> We noticed that there was a significant drop in performance when entering 
> page mode in the case of multiple subscribers.
> We created a topic and 100 queues bound to it. We ran our _GrinderRunner 
> test_ in our inner test infra cluster with 500 threads producing message and 
> 560 threads, each one picked a random queue to subscribe. The test showed 
> performance is bad: 13000 msg/s sent and 5000 msg/s received.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Reply via email to