[
https://issues.apache.org/jira/browse/CASSANDRA-12848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379360#comment-16379360
]
Chris Lohfink commented on CASSANDRA-12848:
-------------------------------------------
The buckets for the EH go in 20% jumps, so everything in a bucket from 700-840
for example will be reported as "840". This means that it will round up to
nearest 20% and all the variance within the 20% is lost. 2.1 was lossy
(randomly threw away latency recordings regardless of how important they are)
but 2.2+ has a 20% error threshold (will in worse case report as 20% worse, not
better)
> Nodetool proxyhistograms/cfhistograms still report latency as flat result
> -------------------------------------------------------------------------
>
> Key: CASSANDRA-12848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12848
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Nutchanon Leelapornudom
> Priority: Major
> Labels: metrics
> Attachments: clientrequest-latency.png, image001.png
>
>
> Even patched in CASSANDRA-11752, nodetool
> proxyhistograms/cfhistograms(2.2)/tablehistograms(3.0,3.x) still report
> read/write latency as flat result. That cause Cassandra metric
> org.apache.cassandra.metrics.ClientRequest.Read/Write.Latency.xxpercentile
> report incorrect pattern.
> I have attached the result which I tested on cassandra 3.0.9. It indicate
> read latency as flat line whereas read count has a movement normally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
