[
https://issues.apache.org/jira/browse/ZOOKEEPER-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal Kathuria updated ZOOKEEPER-1148:
---------------------------------------
Attachment: zookeeperEverything.patch
This is a patch that I am uploading for sharing with Patrick. It is NOT ready
for review.
In this patch, I have prototyped local sessions and multi-threaded reads.
This patch does that for all sessions and not just for readOnly sessions, hence
it is not correct. I created this patch to find out the potential throughput
gain from multi-threading reads and having local sessions.
In my workload, this patch gave 6X improvement. This patch is not sync'd to the
latest in the trunk.
> Multi-threaded handling of reads
> ---------------------------------
>
> Key: ZOOKEEPER-1148
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1148
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Reporter: Vishal Kathuria
> Fix For: 3.5.0
>
> Attachments: zookeeperEverything.patch
>
>
> This improvement is to take advantage of multiple cores in the machines that
> typically run ZooKeeper servers to get higher read throughput.
> The challenge with multiple threads is read/write ordering guarantees that
> ZooKeeper provides.
> One way of handling these is to let readOnly clients use the multiple
> threads, and the read/write clients continue to use the same single
> CommitProcessor thread for both reads and writes. For this to work, a client
> would have to declare its readOnly intent through a flag at connect time. (We
> already have a readOnly flag, but its intent is a bit different).
> Another way of honoring the read/write guarantee is to let all sessions start
> as readOnly sessions and have them use the multi-threaded reads until they do
> their first write. Once a session performs a write, it automatically flips
> from a read/write session to a read only session and starts using the single
> threaded CommitProcessor. This is a little tricky as one has to worry about
> in flight reads when the write comes and we have to make sure those reads
> finish before the write goes through.
> I would like to get the community's feedback on whether it would be useful to
> have this and whether an automatic discovery of readOnly or read/write intent
> is critical for this to be useful. For us, the clients know at connect time
> whether they will ever do a write or not, so an automatic detection is of
> limited use.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
