[jira] [Created] (HBASE-29222) Avoid expensive tracing calls if tracing is disabled

["Becker Ewing (Jira)" <ji...@apache.org>]

Becker Ewing created HBASE-29222:
------------------------------------

             Summary: Avoid expensive tracing calls if tracing is disabled
                 Key: HBASE-29222
                 URL: https://issues.apache.org/jira/browse/HBASE-29222
             Project: HBase
          Issue Type: Improvement
    Affects Versions: 2.6.2, 2.5.11, 3.0.0-beta-1
            Reporter: Becker Ewing
            Assignee: Becker Ewing
         Attachments: slow-decompressor-reinit.2.html

Building off of https://issues.apache.org/jira/browse/HBASE-29099—where we removed certain expensive calls if tracing was disabled—it appears that there is more opportunities to avoid allocating/recording trace metadata if we can determine that a trace is disabled. 

This is inspired by a glance at the first flamegraph in https://issues.apache.org/jira/browse/HBASE-29218 where we spent an aggregate 1.48% of all CPU time in OpenTelemetry calls (I filtered for "io/opentelem"). Given that tracing is an opt-in feature, we ideally shouldn't impose a performance penalty if it isn't enabled. Span Calls in the Block I/O Path (particularly those in BlockIOUtils & HFileBlock) look to dominate this flamegraph. We should ensure that we're only recording expensive attributes if tracing is enabled in those paths. 

As it stands now, BlockIOUtils#readWithExtra spends 40% of it's time in OpenTelemetry calls and the rest of it's time reading data from the filesystem which shows the non-trivial nature of the tracing context being recorded.



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