[
https://issues.apache.org/jira/browse/CASSANDRA-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479683#comment-16479683
]
Ariel Weisberg commented on CASSANDRA-14448:
--------------------------------------------
bq. 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.
I'm not sure what you are proposing here as a change?
It's not 100% clear to me that separating prepare from read is better under
contention. It's an extra roundtrip where proposers can duel right? Contended
CAS throughput is so low that the bottleneck is not read capacity so shrinking
the window in which proposers can duel should decrease the likelihood of
contention.
I think if you implement it and have clients generate contending CAS requests
with a random arrival distribution you would see an improvement.
bq. I think my suggestion here is to emphasize the performance difference of
using consistency level ANY or not, in the CAS operation.
I'm confused. What do you mean emphasize? Like update the docs and make it
clear?
As Jordan pointed out the CL of commit does matter and ANY is the only one
where it being asynchronous is OK. If you want asynchronous commit I don't see
why ANY doesn't match what you are looking for?
> 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: [email protected]
For additional commands, e-mail: [email protected]
