Sylvain Lebresne commented on CASSANDRA-14448:

bq. Combine prepare and quorum read together

Certainly Worth experimenting with.

It's a tradeoff though, not a clear cut optimization: it will certainly speed 
up the non-contended case, but every time the prepare fails, you will have 
wasted time/resources on some reads, which might impact contended performance 
(hard to say how much of course without at least experimenting). Not saying 
this isn't the right tradeoff either btw, just that we shouldn't commit that 
kind of changes without a decent performanca analysis.

bq. Propose new value, and then send out the commit request asynchronously, so 
client will not wait for the ack of the commit.

I'm less sure on this one. First, let's remind that the commit phase is already 
(optionally) somewhat asynchronous: it has it's own consistency level that 
allow users to control this.

Now, granted, we have no {{ConsistencyLevel.ZERO}} so it cannot be 100% 
asynchronous and I assume that is what you suggest adding?

But to be honest, I'm unconvinced it's worth feature creeping for this: adding 
a {{ConsistencyLevel.ZERO}} is going to confuse the hell out of users (in 
general), and adding a completely separate flag to turn that on when we already 
have the "consistentyForCommit" tunable is also pretty confusing (because super 

Further, for a given CAS write, you cannot do additional writes or read that 
write until the commit is somewhat effectively propagated. So that while I'm 
sure a fully asynchronous commit mode could make some unrealistic benchmark 
look good, it's less clear to me that this would make a truly meaningful 
difference in real life scenarios.

Unless I actually misunderstand the extent of what you are suggesting here of 

> Improve the performance of CAS
> ------------------------------
>                 Key: CASSANDRA-14448
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14448
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Coordination
>            Reporter: Dikang Gu
>            Assignee: Dikang Gu
>            Priority: Major
> I'm working on some performance improvements of the lightweight transitions 
> (compare and set).
> 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 asynchronously, 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 using 2 
> rounds trips. There can be following improvements as well, and this can be a 
> start point.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to