[
https://issues.apache.org/jira/browse/SOLR-14401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717364#comment-17717364
]
David Smiley commented on SOLR-14401:
-------------------------------------
[~patson] -- (assuming I understand you correctly), the change here was
deliberate. The intention is that "QUERY./select.requestTimes" (plainly; not
having .distrib, .local, [shard], whatever tagging) shows statistics on
requests that are not sub-requests / components that roll up to a higher level
request. But I'm a little confused what you say; you refer to a "former case"
and "both" but it may not matter if you understand my intent any way. You
could tweak your client's request to add "isShard=true".
> "distrib" request handler metrics should only be tracked on pertinent handlers
> ------------------------------------------------------------------------------
>
> Key: SOLR-14401
> URL: https://issues.apache.org/jira/browse/SOLR-14401
> Project: Solr
> Issue Type: Improvement
> Components: metrics
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Blocker
> Fix For: 9.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> SOLR-13979 in 8.4 added separate request handler metrics for distributed
> requests. However this was done for _all_ request handlers, even though it's
> mainly SearchHandler (and maybe one or two others?) where a distributed
> request is even possible. I refer to this as "metrics pollution" and it's a
> bad thing. It's more weight per handler (latency load & memory), more weight
> for Solr metrics responses, and it's also _suggestive_ that all registered
> handlers can have distributed requests when this is quite false, thus
> confusing people.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
