[
https://issues.apache.org/jira/browse/PHOENIX-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650819#comment-17650819
]
ASF GitHub Bot commented on PHOENIX-6052:
-----------------------------------------
mnpoonia commented on PR #1546:
URL: https://github.com/apache/phoenix/pull/1546#issuecomment-1361155902
@tkhurana i think it is upto us. Ultimately we care about how much time one
mutation took. Now if we want to divide it in syscat and then htable.batch it
is perfectly fine but not sure if we want to introduce a new metric.
As per the discussion in JIRA
https://issues.apache.org/jira/browse/PHOENIX-6052 It looked like we are not in
favor of new metric so i went ahead with this approach.
@virajjasani and @shahrs87 what do you guys think?
> 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)
