[
https://issues.apache.org/jira/browse/HBASE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793099#comment-16793099
]
Andrew Purtell commented on HBASE-21805:
----------------------------------------
Took a look at this. Turns out this is difficult to achieve due to various
interface encapsulations. Call time metrics are calculated and available at the
RpcServer level. We hide information about call particulars from this layer. If
we wanted to track RPC level metrics by table we would have to break this
abstraction and extract table name, if relevant, from the call parameters.
Furthermore we would need to plumb access to the regionserver's table metric
histograms into the RPC server. Doesn't seem worth it, in my opinion.
> Extend per table metrics with some RPC layer measures
> -----------------------------------------------------
>
> Key: HBASE-21805
> URL: https://issues.apache.org/jira/browse/HBASE-21805
> Project: HBase
> Issue Type: Improvement
> Components: metrics, rpc
> Reporter: Andrew Purtell
> Priority: Minor
>
> RPC metrics are whole server in scope. We should extend the per-table metrics
> to also track a subset of RPC metrics on a per table basis. This would give
> better insight into the subjective experience of each use case.
> Consider TotalCallTime, ProcessCallTime, QueueCallTime. Table metrics already
> track request counts and server side processing latencies, just not queueing
> effects at the RPC layer.
> Ideally we avoid introducing another configuration option but this could be
> made optional, if overheads are significant (measure them)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
