commit ba71d71c0b517b4e19ba151b29a7e3aac84809ab
author Edwin Kempin <ekempin@google.com> Mon Jul 15 07:34:12 2024 +0000
committer Edwin Kempin <ekempin@google.com> Mon Jul 15 07:49:12 2024 +0000
tree d1b3e6d0e38cee564e0d252f289f8e022a9fc6e5
parent fc318712756023ca7d301b4aca653812ee3d0e22

PerformanceMetrics: Log per request latency for configured operations

PerformanceMetrics has 2 metrics, one to record the latency of the
configured operations and one to count how often the configured
operations are invoked in total. To be able to estimate how much a
latency improvement improves the latency for a request, we add a third
metric that records the total latency of calling the configured
operations during one request. This way we can know how much a certain
operation contributes to the request latency in total, and how much a
latency improvement speeds up the request.

E.g. at Google we migrate the accounts from NoteDb into another storage
and we hope this will speed up the "Loading account" operations which
can be called many times during a request. Having the new metric allows
us to see how much the latency of the different requests is improved by
this migration. Without the new metric we would only know how the
latency of the "Loading account" operation is improved, but not which
effect this had on the request latencies.

To know the total latency of the configured operations we sum up the
latency per operation in memory when the logNanos methods are invoked.
Then we use the total latency to record the new metric in a new
PerformanceLogger#done() method that is invoked after all logs have been
written. To be able to cache the total latency in memory the
PerformanceMetrics PerformanceLogger can no longer be a singleton, but
we need a new instance for every request.

Release-Notes: skip
Change-Id: I42fc1ab6328723fa05b0ed04979eef75f19f8d51
Signed-off-by: Edwin Kempin <ekempin@google.com>