[
https://issues.apache.org/jira/browse/HBASE-14869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-14869:
----------------------------------
Attachment: 14869-test-0.98.txt
Had a few minutes to work on this. Simple patch.
_Totally untested, might not even compile, just had to park it somewhere_.
You get the idea, though, for the value passing through, find the right range,
and increment that ranges value. Upon snapshot report all ranges.
I went log3 up to 30s, then thoughts it's better to roughly double (60s, 120s,
300s, 600s, > 600s)
Note, this is now reported _everywhere_ where use MutableHistogram. Since the
ranges cover 1ms-10mins, we can use the same for gets and snapshots, so it
should be OK.
> Better request latency histograms
> ---------------------------------
>
> Key: HBASE-14869
> URL: https://issues.apache.org/jira/browse/HBASE-14869
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Lars Hofhansl
> Attachments: 14869-test-0.98.txt
>
>
> I just discussed this with a colleague.
> The get, put, etc, histograms that each region server keeps are somewhat
> useless (depending on what you want to achieve of course), as they are
> aggregated and calculated by each region server.
> It would be better to record the number of requests in certainly latency
> bands in addition to what we do now.
> For example the number of gets that took 0-5ms, 6-10ms, 10-20ms, 20-50ms,
> 50-100ms, 100-1000ms, > 1000ms, etc. (just as an example, should be
> configurable).
> That way we can do further calculations after the fact, and answer questions
> like: How often did we miss our SLA? Percentage of requests that missed an
> SLA, etc.
> Comments?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
