[
https://issues.apache.org/jira/browse/ZOOKEEPER-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15284008#comment-15284008
]
Flavio Junqueira commented on ZOOKEEPER-2024:
---------------------------------------------
I appreciate the concern with the community and fully agree about jira
turnaround. However, the limited time the contributors of this project have had
have been focusing on solving critical issues that affect ZooKeeper in
production. This jira was lined up for trunk, so it really was lower in my
priority list because I'm investing time in the blockers for 3.5.2, and I think
it is the same for several of the other contributors. We do wait for people to
+1 it, no matter how irritating the wait might be (and it often is), sometimes
even pinging them outside the list. Specifically to this jira, there aren't
that many active people here, so you could easily have just pinged everyone. In
fact, I think it is just [~rgs] and I.
I really want to make a big deal out of this because I don't want to see this
kind of behavior again in other jiras. I like much better the approach much of
getting reviewers to clearly state their approval, and the fact that a jira
doesn't get the priority you'd like, doesn't mean you should bypass. Please
wait for the votes next time and ping people accordingly. And let's work on
your suggestion of not holding jiras for long, I'm all for it.
[~kfirlevari] I apologize for the wait and thanks for contributing.
> 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
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2024.patch, ZOOKEEPER-2024.patch,
> ZOOKEEPER-2024.patch, ZOOKEEPER-2024.patch, ZOOKEEPER-2024.patch,
> ZOOKEEPER-2024.patch, ZOOKEEPER-2024.patch, ZOOKEEPER-2024.patch,
> ZOOKEEPER-2024.patch, ZOOKEEPER-2024.patch, ZOOKEEPER-2024.patch,
> ZOOKEEPER-2024.patch, 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.
> Please see the docs:
> 1) https://goo.gl/m1cINJ - 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://goo.gl/W0xDUP - performance results.
> (See https://issues.apache.org/jira/browse/ZOOKEEPER-2023 for the
> corresponding new system test that produced these performance measurements)
>
> See also https://issues.apache.org/jira/browse/ZOOKEEPER-1609
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
