[
https://issues.apache.org/jira/browse/BOOKKEEPER-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504370#comment-13504370
]
Sijie Guo commented on BOOKKEEPER-461:
--------------------------------------
> what are the big dips?
the figure is formed by several benchmark runs. so the drop is between
benchmarks and the figure is collected from hub server side not from benchmark.
> The new code moves the cache cleanup from being synchronous to be
> asynchronous. I.e. If the read ahead cache is getting too full, schedule a
> flush. This doesn't block many more requests trying to add to the cache
> before it has been cleaned up.
This is a good point. I will try looking into it and think about your
suggestion using CacheBuilder.
> Delivery throughput degrades when there are lots of publishers w/ high
> traffic.
> -------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-461
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-461
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Sijie Guo
> Assignee: Sijie Guo
> Fix For: 4.2.0
>
> Attachments: BOOKKEEPER-461.diff, BOOKKEEPER-461.diff,
> BOOKKEEPER-461.diff, pub_sub_multithreads.png, pub_sub_singlethread.png
>
>
> When running benchmarking over the hub server, found that delivery throughput
> degrades when there are lots of publishers publishing messages. And the
> delivery throughput will goes up when there is no publishes.
> This issue is introduced due to ReadAheadCache only runs a single thread. So
> when the netty workers are busy handling publish requests, they are pushing
> lots of messages into ReadAheadCache's queue to put them in to read ahead
> cache. So the readahead cache is busy on updating keys.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
