cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nitsan Wakart (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11853) Improve Cassandra-Stress latency measurement
Date Tue, 24 May 2016 14:45:13 GMT


Nitsan Wakart commented on CASSANDRA-11853:

Addressed now:
- code style (apologies where I missed it, I try to no wholesale format for patches which
makes me miss the occasional bracket)
- Add dependency to build
- Added comments
- Synchronize consumer starting point and set that as the rate limiter start reference point
to minimize observed initial latency.

"If the rate limit is set too high, such that stress can't keep up with the expected rate,
the results will make no sense. The actual start time will be way after the limiters calculated
start time."
If the rate limit is too high the results should reflect the failure IMO. You asked for 100K
per sec and the cluster can only serve 1K would lead to breached SLA in real life and the
reported latencies will reflect it. The results make perfect sense in that they show failure.

For clarification, the 'latency' figure now reported for throttled runs is now response time
rather than service time. The hdr log contains data for response/service/wait time following
this definition:

Let each operation have an intended start time(Ti) (e.g. based on throttle), an actual start
time(Ta), and an end time(Te), then for each operation we can define response time(Te - Ti),
service time (Te - Ta) and wait time(Ta - Ti). When no intended time is available (e.g. throughput
run) we can set it to actual start time in which case response time is the same as service
time and wait time is zero.

We could have the summary report the service time alongside the response time, but that may
break down stream reporting.

> Improve Cassandra-Stress latency measurement
> --------------------------------------------
>                 Key: CASSANDRA-11853
>                 URL:
>             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:

This message was sent by Atlassian JIRA

View raw message