Github user qihongxu commented on the issue:
https://github.com/apache/activemq-artemis/pull/2484
> @qihongxu,
>
> re:
> "
> According to this we have an internal branch that removes isPaging()
methodâs readlock in PagingStoreImpl, along with adding pageSyncTimerâs
specific executor. After that we performed a same test and get a result of
21k/25k Send&Receiveâin total 46k TPS. This version runs smoothly in our use
case but we are still exploring potential effects.
> "
>
> Agree that as the QueueImpl:checkDepage which is called from deliver
method, only schedules another depage asynchronously that the read barrier lock
for that is over kill as it doesn't have to be strongly consistent correct.
>
> I think changing the current method could be dangerous, unless we do a
fuller analysis on all its uses, but i think we could easily add a new method
named something like "isPagingDirtyRead" which can return without the readlock,
it will mean the returned value isn't always 100% accurate but in cases such as
checkDepage, we don't need it to be, its just a single, and we can call it
where we know its safe to.
>
> Would you be happy adding this, (will need to be exposed via
PageSubscription)? And updating checkDepage to use that one?
As you suggested we tried update checkDepage with a new "isPagingDirtyRead"
method which can return without the readlock. But after running same tests on
this version it seems that checkDepage did not affect receive performance too
much. Instead, CursorIterator#hasNext in PageSubscriptionImpl also called
isPaging() and had a significant impact on receive performance. According to
this we updated hasNext() and forced it to use the new âisPagingDirtyReadâ.
Below is the result chart.
(P.S the original ver is a control group, not exactly the âoriginalâ
master-branch build. It has been applied with specific pageSyncTimer executor,
and cache durable in PageReference - See PR Artemis-2214.)
 | Send&Receive | In Total
-- | -- | --
Ver Original | 30k/12.5k | 32.5k
Ver Modified checkDepage | 31.1k/11.3k | 42.4k
Ver Modified hasNext | 23.8k/23.5k | 47.3k
Detailed TPS chart can be seen in attachment. (Sorry we dont have enough
time for running tests. Just got back to work today)
[TPS
chart.docx](https://github.com/apache/activemq-artemis/files/2723731/TPS.chart.docx)
---