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

Nitsan Wakart commented on CASSANDRA-11853:
-------------------------------------------

The option is not called throttle but 'limit', e.g. " -rate limit=1000/s". And 
the description is "limit operations per second across all clients".
I assumed (and have seen others do the same) that the intent is to describe a 
sustainable rate for the benchmark to run at.
So in my interpretation limit means "limit the request rate to X", which does 
not imply "request rate <= X is also fine". The same option for YCSB is called 
"target". I'm not aware of any load generator in which a "limit" mode exists in 
the sense of "run at an operation rate <= X", but perhaps it's a feature.

If the use of "limit" is confusing we could perhaps add a new mode called 
"target" with this meaning and have "limit" not set the intended start time 
since it does not imply a schedule. Or keep it as is and rename "limit" to 
"target".

The CASSANDRA-8686 feature is far more complex as it assumes you have some 
notion of SLA and that you can tweak load dynamically to find the SLA breaking 
point. Having implemented an attempt or 2 in that direction I can say it makes 
an interesting, but ultimately unreliable testing mode. I think it is better to 
leave the 'verdict' phase to tooling external to the load gen, and in any case 
would not mix this patch with a "find max load while matching SLA point" tool.

> Improve Cassandra-Stress latency measurement
> --------------------------------------------
>
>                 Key: CASSANDRA-11853
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11853
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tools
>            Reporter: Nitsan Wakart
>            Assignee: Nitsan Wakart
>             Fix For: 3.x
>
>
> Currently CS reports latency using a sampling latency container and reporting 
> service time (as opposed to response time from intended schedule) leading to 
> coordinated omission.
> Fixed here:
> https://github.com/nitsanw/cassandra/tree/co-correction



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to