[ 
https://issues.apache.org/jira/browse/CASSANDRA-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479653#comment-16479653
 ] 

Dikang Gu edited comment on CASSANDRA-14448 at 5/17/18 8:27 PM:
----------------------------------------------------------------

Thanks everyone for reply!

It is a trade-off. I assume non-contended cases are the majority, and local 
read is cheaper than cross DC network requests. Under this assumption, it's a 
right (at least worth try) trade-off to me. For the contended case, as a 
potential improvement, we can make the replica skip the data read, if it 
already promised on a bigger ballot than the prepared one. But for other 
replicas, we will read the local data, which might be wasted, if the ballot is 
not accepted. 

For the async commit, currently it uses "_boolean shouldBlock = 
consistencyLevel != ConsistencyLevel.ANY"_ to decide to whether wait for Ack or 
not. I think my suggestion here is to emphasize the performance difference of 
using consistency level ANY or not, in the CAS operation.


was (Author: dikanggu):
Thanks everyone for reply!

It is a trade-off. I assume non-contended cases are the majority, and local 
read is cheaper than cross DC network requests. Under this assumption, it's a 
right (at least worth try) trade-off to me. For the contended case, as a 
potential improvement, we can make the replica skip the data read, if it 
already promised on a bigger ballot than the prepared one. But for other 
replicas, we will read the local data, which might be wasted, if the ballot is 
not accepted. 

For the async commit, currently it uses "_boolean shouldBlock = 
consistencyLevel != ConsistencyLevel.ANY"_ to __ decide whether wait for Ack or 
not. I think my suggestion here is to emphasize the performance difference of 
using consistency level ANY or not, in the CAS operation.

> 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
(v7.6.3#76005)

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

Reply via email to