[
https://issues.apache.org/jira/browse/ARTEMIS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16730776#comment-16730776
]
ASF GitHub Bot commented on ARTEMIS-2216:
-----------------------------------------
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2484
Comments on this are:
We have shared executor and thread pools as a way to pool these its part
artemis design so that these can be controlled, eg the number of threads are
configurable. And theres uses cases for why, we dont just add executors. If we
add a new pool it should be configurable like others.
Whilst your use case this significantly improves things. As you note this
change isnt entirely positive to all users as it does impact use cases where
people may care more on the consumer side (i am one one of those). If anything
if the broker is saturated its more important consumers for us can dequeue and
if anything producers backpressure. As if consumers cant keep up and producer
peak continues you can very soon end up situation where paging depth will just
grow and grow.
It would be good to get more stats therefore on how as producer rates ramup
how consumer rates ramp down. And crticial cross over points. Along with number
of remote consumers and producers. All of this could be mute if there is a way
to eliminate the negative effect this change has.
> 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
>
> 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)
