cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6199) Improve Stress Tool
Date Mon, 14 Oct 2013 22:35:42 GMT

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

Jonathan Ellis commented on CASSANDRA-6199:
-------------------------------------------

bq. Do not trash first/last 10% of readings

Would be nice to fix last but I don't see how first 10% can stay valid b/c of JVM warmup.
 Note that

bq. Short warm-up period, which is ignored for summary

is problematic b/c this does affect server results (compaction) during the post-warmup phase.

bq. Per thread Random

FBUtilities has an implementation, incidentally.

> Improve Stress Tool
> -------------------
>
>                 Key: CASSANDRA-6199
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6199
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Tools
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>
> The stress tool could do with sprucing up. The following is a list of essential improvements
and things that would be nice to have.
> Essential:
> - Reduce variability of results, especially start/end tails. Do not trash first/last
10% of readings
> - Reduce contention/overhead in stress to increase overall throughput
> - Short warm-up period, which is ignored for summary (or summarised separately), though
prints progress as usual. Potentially automatic detection of rate levelling.
> - Per thread Random
> Nice to have:
> - Calculate and print stdev and mean
> - Add batched sequential access mode (where a single thread performs batch-size sequential
requests before selecting another random key) to test how key proximity affects performance
> - Auto-mode which attempts to establish the maximum throughput rate, by varying the thread
count (or otherwise gating the number of parallel requests) for some period, then configures
rate limit or thread count to test performance at e.g. 30%, 50%, 70%, 90%, 120%, 150% and
unconstrained.
> - Auto-mode could have a target variance ratio for mean throughput and/or latency, and
completes a test once this target is hit for x intervals
> Also, remove the skip-key setting, as it is currently ignored. Unless somebody knows
the reason for it.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message