[
https://issues.apache.org/jira/browse/CASSANDRA-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478755#comment-16478755
]
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
inconsistent/random).
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
course.
> 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
