[NEW] Add finer granularity latency sampling

[sjpotter]

The problem/use-case that the feature addresses

Currently Redis only supports latency sampling at the millisecond level, this is insufficient for our needs with RedisRaft where we need at least microsecond granularity.

Description of the feature

The idea is that Redis should always store latency measurements in the finer granularity (either micro or nanoseconds). New APIs would be added that take that granularity and exiting APIs would wrap the new APIs with multiplication/division by the appropriate factor to remain compatible.

Alternatives you've considered

Writing our own sampling infrastructure, but seems a waste to not be able to reuse the existing infrastructure and that others might want finer granularity as well.

[oranagra]

@sjpotter are you referring to RM_LatencyAddSample and the LATENCY LATEST / HISTORY commands?
or something else?

are you suggesting to add RM_LatencyAddSampleMicros, a new latency-monitor-threshold-micros config, and some units argument to LATENCY LATEST and LATENCY HISTORY?

[sjpotter]

I'm talking about both. "inputting" and "outputting" the samples. i.e. today , one can only add latency samples in milliseconds, and since its stored as such the LATENCY command only operates on milliseconds.

I'm proposing that we should store everything in finer granularity with new APIs that take the finer granularity (and old APIs just wrap new APIs be internal to redis or exposed via RM API with a factor to convert to finer granularity)

In terms of "output" (LATENCY LATEST, LATENCY HISTORY... or any RM APIs that allow you to access sample data) I'd say yes, adding a unit arguments (with the default either being set by a redis config option or just the current milliseconds) for backwards compatibility.