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)
