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

Benedict commented on CASSANDRA-7542:
-------------------------------------

OK. Not sure if it is worth our pursuing this right now then, at least as far 
as a 2.0 delivery is concerned. When I get some more free time I'll create some 
benchmarks to test how much of an improvement these (or future) changes have.

> Reduce CAS contention
> ---------------------
>
>                 Key: CASSANDRA-7542
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7542
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: sankalp kohli
>            Assignee: Benedict
>             Fix For: 2.0.10
>
>
> CAS updates on same CQL partition can lead to heavy contention inside C*. I 
> am looking for simple ways(no algorithmic changes) to reduce contention as 
> the penalty of it is high in terms of latency, specially for reads. 
> We can put some sort of synchronization on CQL partition at StorageProxy 
> level. This will reduce contention at least for all requests landing on one 
> box for same partition. 
> Here is an example of why it will help:
> 1) Say 1 write and 2 read CAS requests for the same partition key is send to 
> C* in parallel. 
> 2) Since client is token-aware, it sends these 3 request to the same C* 
> instance A. (Lets assume that all 3 requests goto same instance A) 
> 3) In this C* instance A, all 3 CAS requests will contend with each other in 
> Paxos. (This is bad)
> To improve contention in 3), what I am proposing is to add a lock on 
> partition key similar to what we do in PaxosState.java to serialize these 3 
> requests. This will remove the contention and improve performance as these 3 
> requests will not collide with each other.
> Another improvement we can do in client is to pick a deterministic live 
> replica for a given partition doing CAS.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to