[
https://issues.apache.org/jira/browse/CASSANDRA-6199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794591#comment-13794591
]
Benedict commented on CASSANDRA-6199:
-------------------------------------
The short warm-up period is meant to take the place of the current arbitrary
imposition of dropping the first 10% of all results. Often this is much more
than needs to be ignored, especially for large tests, so it should at least be
an improvement from what we currently have.
As to affecting the post warm-up phase, this is true for writes, but I would
note again both that this change should reduce the problem, and that whilst it
is fairly difficult to avoid the problem entirely, assuming a constant rate of
stress any latent effects should reach a steady state at some point - hence the
idea of an auto mode, which attempts to establish the steady state and report
this, as opposed to running for n iterations. If analysing a graph of the
results for n iterations any warm-up period would be included anyway, and could
be understood, as is currently the case.
bq. FBUtilities has an implementation, incidentally.
In this case simple creating a Random in each thread should be the easiest
solution, thread local isn't really helpful here.
> 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)
