[router] remove store level metrics for non-streaming multiget #1306
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The store level metrics in AggRouterHttpRequestStats are registered lazily. Add a flag in AggRouterHttpRequestStats to disable store level metric emission for non-streaming multiget request type. This is cleaner and the less intrusive than adding checks and handling elsewhere because AggRouterHttpRequestStats and the triggers to corresponding record functions are shared across different request types (SINGLE_GET, MULTI_GET, MULTI_GET_STREAMING, COMPUTE, etc...). We will keep the total stats for non-streaming multiget to give us visibility in case any legacy clients start to make non-streaming multiget requests. Fixed a bug where recordNoAvailableReplicaAbortedRetryRequest was calling the wrong method for the store metric recording.
KaiSernLim
approved these changes
Nov 21, 2024
There was a problem hiding this comment.
@m-nagarajan FYI: This PR will introduce some merge conflicts for #1303.
m-nagarajan
reviewed
Nov 21, 2024
| @@ -29,14 +32,18 @@ public AggRouterHttpRequestStats( | |||
| ReadOnlyStoreRepository metadataRepository, | |||
| boolean isUnregisterMetricForDeletedStoreEnabled) { | |||
| super(metricsRepository, metadataRepository, isUnregisterMetricForDeletedStoreEnabled); | |||
| // Disable store level non-streaming multi get stats reporting because it's no longer used in clients. We still | |||
| // report to the total stats for visibility of potential old clients. | |||
| isStoreStatsEnabled = !RequestType.MULTI_GET.equals(requestType); | |||
There was a problem hiding this comment.
Should we just remove MULTI_GET? Do we have any use cases for this?
m-nagarajan
reviewed
Nov 22, 2024
| if (isStoreStatsEnabled) { | ||
| return scatterGatherStatsMap.computeIfAbsent(storeName, k -> new ScatterGatherStats()); | ||
| } else { | ||
| return totalScatterGatherStats; |
There was a problem hiding this comment.
Will this result in dual recording of the total stats?
if we are checking isStoreStatsEnabled and not recording the store stats as seen in recordStoreStats(), should we clean this to not return anything?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[router] remove store level metrics for non-streaming multiget
The store level metrics in AggRouterHttpRequestStats are registered lazily. Add a flag in AggRouterHttpRequestStats to disable store level metric emission for non-streaming multiget request type. This is cleaner and the less intrusive than adding checks and handling elsewhere because AggRouterHttpRequestStats and the triggers to corresponding record functions are shared across different request types (SINGLE_GET, MULTI_GET, MULTI_GET_STREAMING, COMPUTE, etc...).
We will keep the total stats for non-streaming multiget to give us visibility in case any legacy clients start to make non-streaming multiget requests.
Fixed a bug where recordNoAvailableReplicaAbortedRetryRequest was calling the wrong method for the store metric recording.
How was this PR tested?
Existing and new tests
Does this PR introduce any user-facing changes?