[
https://issues.apache.org/jira/browse/HBASE-12117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152868#comment-14152868
]
Andrew Purtell commented on HBASE-12117:
----------------------------------------
This was YCSB running against an all localhost 0.98 cluster. The old YCSB
client. This is workload C. traces.client.getHTable.svg is traces.client.c.svg
with all sampled call arcs filtered out except those that go through getHTable,
in effect zooming in on a portion of the full trace. Workload C is an all read
workload. This is a client trace.
> Constructors that use Configuration may be harmful
> --------------------------------------------------
>
> Key: HBASE-12117
> URL: https://issues.apache.org/jira/browse/HBASE-12117
> Project: HBase
> Issue Type: Improvement
> Reporter: Andrew Purtell
> Attachments: traces.client.c.svg, traces.client.getHTable.svg
>
>
> There's a common pattern in HBase code where in the constructor, or in an
> initialization method also called once per instantiation, or both, we look up
> values from Hadoop Configuration and store them into fields. This can be
> expensive if the object is frequently created. Configuration is a heavyweight
> registry that does a lot of string operations and regex matching. See
> attached example. Method calls into Configuration account for 48.25% of CPU
> time when creating the HTable object in 0.98. (The remainder is spent
> instantiating the RPC controller via reflection, a separate issue that merits
> followup elsewhere.) Creation of HTable instances is expected to be a
> lightweight operation if a client is using unmanaged HConnections; however
> creating HTable instances takes up about 18% of the client's total on-CPU
> time. This is just one example where constructors that use Configuration may
> be harmful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
