[CASSANDRA-16760] JMXTimer exposes attributes in inconsistent time units

• Type: Improvement
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 4.1-alpha1, 4.1
• Component/s: Legacy/Observability
• Change Category: Semantic
• Complexity: Normal
• Platform: All

Source Control Link

https://github.com/apache/cassandra/commit/845077fbc8d7102f303372eb8cb3299a155a436e https://github.com/apache/cassandra-dtest/commit/7bf5be87e1d37e9f9302f15b1b79a48b0082b521

Test and Documentation Plan

CI

• Assignee: Yifan Cai
• Reporter: Yifan Cai

Authors

Yifan Cai

Reviewers

Caleb Rackliffe

• Created: 24/Jun/21 00:14
• Updated: 27/May/22 19:25
• Resolved: 16/Jul/21 17:25

Description

JMXTimer objects are constructed with a duration time unit, which is fixed to MICROSECONDS in the codebase. According to that, we should expect the time values returned from the JXMTimer are in micros.

However, the time unit is inconsistent among the JMXTimer attributes.
Most of the attributes such as percentiles and mean values returned are in micros, except Values and RecentValues.
Those 2 attributes expose the raw histogram values of the underlying Timer (CodaHale) and the values are fixed to be based on nanos.

The inconsistency leads to confusion and mis-interpretation of the values, if the end user is not familiar with the implementation details. One may consider the Values and RecentValues are also in micros.
Besides the confusion, given the intention is to record the time values in the micros resolution, we do not need to allocate 165 buckets in the DecayingEstimatedHistogramReservoir. 165 buckets is necessary for nanos, but not for micros. We can only allocate 90 buckets and it should reduce ~50% memory footprint used by the Timers.

I'd like to propose an approach to scale the values being recorded in the reservoirs used by Timers and reduce the allocation.