[jira] [Created] (HBASE-27699) User metrics for filtered and read rows are too expensive

["Bryan Beaudreault (Jira)" <ji...@apache.org>]

Bryan Beaudreault created HBASE-27699:
-----------------------------------------

             Summary: User metrics for filtered and read rows are too expensive
                 Key: HBASE-27699
                 URL: https://issues.apache.org/jira/browse/HBASE-27699
             Project: HBase
          Issue Type: Improvement
            Reporter: Bryan Beaudreault


MetricsUserAggregateImpl has a pattern like this:
{code:java}
String user = getActiveUser();
if (user != null) {
  MetricsUserSource userSource = getOrCreateMetricsUser(user);
  incrementFilteredReadRequests(userSource);
} {code}
So every update involves a getOrCreate call, which does a ConcurrentHashMap lookup. This overhead is not too bad for most requests, because it's just executed once per request (i.e. updatePut gets called once at the end, though multi's it happens for every action).

For updateFilteredReadRequests and updateReadRequestCount, these are currently called in RegionScannerImpl for every row scanned or filtered.  Doing the map lookup over and over adds up. Profiling the regionserver under load, I see over 5% of the time spent updating these metrics.

We should try to collect these metrics maybe in the RpcCallContext, and the translate into user metrics once at the end of the request. Or otherwise find a way to minimize querying the ConcurrentHashMap multiple times in the context of a request. Maybe we should actually stash the MetricsUserSource in the RpcCallContext so that all user metrics only need to do the lookup once, even for multi's.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)