[jira] [Work logged] (ARTEMIS-2216) Use a specific executor for pageSyncTimer

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

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

                Author: ASF GitHub Bot
            Created on: 14/Jan/19 16:40
            Start Date: 14/Jan/19 16:40
    Worklog Time Spent: 10m 
      Work Description: asfgit commented on pull request #2484: ARTEMIS-2216 Use a specific executor for pageSyncTimer
URL: https://github.com/apache/activemq-artemis/pull/2484
 
 
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


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

            Worklog Id:     (was: 184889)
            Time Spent: 10m
    Remaining Estimate: 0h

> Use a specific executor for pageSyncTimer
> -----------------------------------------
>
>                 Key: ARTEMIS-2216
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2216
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>    Affects Versions: 2.6.3
>            Reporter: Qihong Xu
>            Priority: Major
>         Attachments: contention_MASTER_global.svg, contention_PR_global.svg, contention_PR_single.svg
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Improving throughput on paging mode is one of our concerns since our cluster uses paging a lot.
> We found that pageSyncTimer in PagingStoreImpl shared the same executor with pageCursorProvider from thread pool. In heavy load scenario like hundreds of consumers receiving messages simultaneously, it became difficult for pageSyncTimer to get the executor due to race condition. Therefore page sync was delayed and producers suffered low throughput.
>  
> To achieve higher performance we assign a specific executor to pageSyncTimer to avoid racing. And we run a small-scale test on a single modified broker.
>  
> Broker: 4C/8G/500G SSD
> Producer: 200 threads, non-transactional send
> Consumer 200 threads, transactional receive
> Message text size: 100-200 bytes randomly
> AddressFullPolicy: PAGE
>  
> Test result：
> | |Only Send TPS|Only Receive TPS|Send&Receive TPS|
> |Original ver|38k|33k|3k/30k|
> |Modified ver|38k|34k|30k/12.5k|
>  
> The chart above shows that on modified broker send TPS improves from “poor” to “extremely fast”, while receive TPS drops from “extremely fast” to “not-bad” under heavy load. Considering consumer systems usually have a long processing chain after receiving messages, we don’t need too fast receive TPS. Instead, we want to guarantee send TPS to cope with traffic peak and lower producer’s delay time. Moreover, send and receive TPS in total raises from 33k to about 43k. From all above this trade-off seems beneficial and acceptable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)