[
https://issues.apache.org/jira/browse/ZOOKEEPER-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118981#comment-14118981
]
Alexander Shraer commented on ZOOKEEPER-2024:
---------------------------------------------
I see. Well, ZK provides guarantees per-session, so you won't have any
guarantees across sessions. Which may be fine if the operations are really
independent.
But I think your intuition makes sense. Instead of multiple sessions (where you
loose all semantics) one could specify relaxed per-operation or per session
semantics. I've actually suggested this in the past here:
http://wiki.apache.org/hadoop/ZooKeeper/MountRemoteZookeeper
The specific ZK property that requires blocking reads after writes of the same
session is prefix/fifo of client requests. So even if the requests are
concurrent (i.e., one didn't complete before the other started) ZK guarantees
that they will complete in invocation order and that if one fails, the ones
invoked after it will fail too.
IIRC the feedback I got was that users expect this fifo property (its reflects
program order) and relaxing it may not be a good idea. But personally I still
think that this can be a good optional feature (either per operation or per
session).
For example, a client's program:
write(v, 1) is invoked
write(v, 1) completes
write(v, 2) is invoked
read(v) is invoked
currently c must return 2. but perhaps the user could say read(v, "I want
sequential consistency without fifo")
which could return either 1 or 2. This could improve the throughput further.
In any case, something like this is probably out of scope for Kfir's proposal
but with Kfir's patch in place it would probably be easier to add in the future.
> Major throughput improvement with mixed workloads
> -------------------------------------------------
>
> Key: ZOOKEEPER-2024
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2024
> Project: ZooKeeper
> Issue Type: Improvement
> Components: quorum, server
> Reporter: Kfir Lev-Ari
> Assignee: Kfir Lev-Ari
> Attachments: ZOOKEEPER-2024.patch
>
>
> The patch is applied to the commit processor, and solves two problems:
> 1. Stalling - once the commit processor encounters a local write request, it
> stalls local processing of all sessions until it receives a commit of that
> request from the leader.
> In mixed workloads, this severely hampers performance as it does not allow
> read-only sessions to proceed at faster speed than read-write ones.
> 2. Starvation - as long as there are read requests to process, older remote
> committed write requests are starved.
> This occurs due to a bug fix
> (https://issues.apache.org/jira/browse/ZOOKEEPER-1505) that forces processing
> of local read requests before handling any committed write. The problem is
> only manifested under high local read load.
> Our solution solves these two problems. It improves throughput in mixed
> workloads (in our tests, by up to 8x), and reduces latency, especially higher
> percentiles (i.e., slowest requests).
> The main idea is to separate sessions that inherently need to stall in order
> to enforce order semantics, from ones that do not need to stall. To this end,
> we add data structures for buffering and managing pending requests of stalled
> sessions; these requests are moved out of the critical path to these data
> structures, allowing continued processing of unaffected sessions.
> In order to avoid starvation, our solution prioritizes committed write
> requests over reads, and enforces fairness among read requests of sessions.
> Please see the docs:
> 1)
> https://docs.google.com/document/d/1oXJiSt9VqL35hCYQRmFuC63ETd0F_g6uApzocgkFe3Y/edit?usp=sharing
> - includes a detailed description of the new commit processor algorithm.
> 2) The attached patch implements our solution, and a collection of related
> unit tests (https://reviews.apache.org/r/25160)
> 3)
> https://docs.google.com/spreadsheets/d/1vmdfsq4WLr92BQO-CGcualE0KhAtjIu3bCaVwYajLo8/edit?usp=sharing
> - shows performance results of running system tests on the patched ZK using
> the patched system test from
> https://issues.apache.org/jira/browse/ZOOKEEPER-2023.
> See also https://issues.apache.org/jira/browse/ZOOKEEPER-1609
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
