Re: Improve the performance of CAS
The idea of combining read with prepare sounds good. Regarding reducing
the commit round trip, it is possible today by giving a lower consistency
level for commit I think.
Regarding EPaxos, it is a large change and will take longer to land. I
think we should do this as it will help lower the latencies a lot.
On Wed, May 16, 2018 at 2:15 PM, Jeremy Hanna <jeremy.hanna1234@xxxxxxxxx>
> Hi Dikang,
> Have you seen Blake’s work on implementing egalitarian paxos or epaxos*?
> That might be helpful for the discussion.
> * https://issues.apache.org/jira/browse/CASSANDRA-6246
> > On May 16, 2018, at 3:37 PM, Dikang Gu <dikang85@xxxxxxxxx> wrote:
> > Hello C* developers,
> > I'm working on some performance improvements of the lightweight
> > (compare and set), I'd like to hear your thoughts about it.
> > As you know, current CAS requires 4 round trips to finish, which is not
> > efficient, especially in cross DC case.
> > 1) Prepare
> > 2) Quorum read current value
> > 3) Propose new value
> > 4) Commit
> > I'm proposing the following improvements to reduce it to 2 round trips,
> > which is:
> > 1) Combine prepare and quorum read together, use only one round trip to
> > decide the ballot and also piggyback the current value in response.
> > 2) Propose new value, and then send out the commit request
> > so client will not wait for the ack of the commit. In case of commit
> > failures, we should still have chance to retry/repair it through hints or
> > following read/cas events.
> > After the improvement, we should be able to finish the CAS operation
> > 2 rounds trips. There can be following improvements as well, and this can
> > be a start point.
> > What do you think? Did I miss anything?
> > Thanks
> > Dikang
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx