[
https://issues.apache.org/jira/browse/ZOOKEEPER-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shraer resolved ZOOKEEPER-1609.
-----------------------------------------
Resolution: Duplicate
I think that this is very similar to what was done with ZOOKEEPER-2024.
It is still the case that the FinalRequestProcessor only accepts a single write
request or multiple reads, and this could perhaps be optimized (though not the
topic of this JIRA), but this would be complex and the benefit is unclear.
> Improve ZooKeeper performance under mixed workload
> --------------------------------------------------
>
> Key: ZOOKEEPER-1609
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1609
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.4.3
> Reporter: Thawan Kooburat
>
> ZOOKEEPER-1505 allows 1 write or N reads to pass through the CommitProcessor
> at any given time. I did performance experiment similar to
> http://wiki.apache.org/hadoop/ZooKeeper/Performance and found that read
> throughput drop dramatically when there are write requests. After a bit more
> investigation, I found that
> the biggest bottleneck is at the request queue entering the CommitProcessor.
> When the CommitProcessor see any write request, it will need to block the
> entire pipeline and wait until matching commit from the leader. This means
> that all read requests (including ping request) won't be able to go through.
> The time spent waiting for commit from the leader far exceed the time spent
> waiting for 1 write to goes through the CommitProcessor.
> The current plan is to create multiple request queues at the front of the
> CommitProcessor. Requests are hashed using sessionId and send to one of the
> queue. Whenever, the CommitProcessor saw a write request on one of the queue
> it moves on to process read requests. It will have to unblock the write
> requests in the same order that it sent to the leader, so it may need to
> maintain a separate list to keep track of that.
> The correctness is the same as having more learners in the ensemble. Sessions
> which are hashed onto a different queue is similar to sessions connecting to
> a different learners in the ensemble.
> I am hoping that this will improve read throughput and reduce disconnect rate
> on an ensemble with large number of clients
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
