> There are several options (all for timers specifically):
>
> 1. Enforce the consistency of the time unit.
> - Change all JMXTimers to store values in micros and reduce the
> bucket size to 90. The change has no impact on reading the
> statistics. But
> the long[] of Values and RecentValues is reduced to 91, and the
> values are
> based on micros.
> - Change all JMXTimer to store values in nanos. The change makes the
> percentiles, mean values returned in nanos. But has no impact on the
> histogram raw values, i.e., Values and RecentValues.
> 2. Having a toggle to either keep the current inconsistency or records
> all in micros. This is less invasive than option 1. And it does not affect
> your monitoring tooling if it reads the Values (histogram raw values) at
> nanos resolution.
>
> I'd prefer option 1. So the DurationUnit attribute correctly annotates the
> other attributes from the JMXTimer. For most of the timers, we do not need
> the nanos resolution. Recording them in micros halves the memory footprint
> for timers. If some timers do need the nanos resolution, the duration unit
> can be changed to nanos. The external process that reads the attributes can
> correctly interpret the values based on the duration unit.
>
> Thoughts?
I'm for (1) if this is for 4.1 only. Changes like this over our annual releases
should be fine if they are clearly documented, it's what NEWS.txt is for.
I'm curious to know any rough idea of how much memory the Timers can currently
use, and which timers we think still need the nano resolution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
