[
https://issues.apache.org/jira/browse/PHOENIX-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651064#comment-17651064
]
Aman Poonia commented on PHOENIX-6052:
--------------------------------------
[~tkhurana] Now that i think of it i think it makes sense to add a separate
catalog metric. This will help us when we have a issue with catalog read
latencies because of high load on the table(orregionserver).
There are two things we can do here
# Add catalog read time to mutation time and also create another metric which
only has the catalog read time.
# create catalog read time metric and keep mutation time metric same as it is
now.
I am inclined towards the #1. That way we get a sense of how much time
mutation took but if we want to drill down we can plot the catalog read time
metric along side to understand how much time out of mutation was spent in
catalog table.
Only thing i am little confused about is how we can corelate between mutation
time and catalog time except maybe the timeline of events.I don't see a thing
binding these two other than that.
> GLOBAL_MUTATION_COMMIT_TIME metric doesn't include the time spent in syscat
> rpc's
> ---------------------------------------------------------------------------------
>
> Key: PHOENIX-6052
> URL: https://issues.apache.org/jira/browse/PHOENIX-6052
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Affects Versions: 4.14.3
> Reporter: Rushabh Shah
> Assignee: Aman Poonia
> Priority: Major
>
> Currently we measure the metric GLOBAL_MUTATION_COMMIT_TIME as the time spent
> just in htable.batch rpc for base and index tables.
> https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/execute/MutationState.java#L1029-L1136
> We don't measure the time spent in
> MutationState#validateAndGetServerTimestamp which makes rpc to SYSTEM.CATALOG
> table and which is a part of commit phase.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
