[
https://issues.apache.org/jira/browse/SOLR-15301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17423811#comment-17423811
]
Andras Salamon commented on SOLR-15301:
---------------------------------------
[~markrmiller] added a comment to the pull request, I copy it here, to keep the
discussion in one place
{quote}Nice, this can be a very expensive call and there is no real limit on
how often metrics may be generated - in a jmx case it was the case and may
still be that for every metric in a group added in a loop, every metrics in
that group was asked to generate.
However, I do wonder about the one off implementation and refresh control.
Almost every metric that exists with more than counter type costs could benefit
from some kind of caching. Time based caching seems like the most predicable
and non surprising approach to limiting frequency and controlling stale value
expectations.
There is a caching metric implementation that simply wraps a metric and I
believe takes a time parameter for how long to cache it. Why not use that
here?{quote}
> Eliminate repetitive index size calculation for Solr metrics
> ------------------------------------------------------------
>
> Key: SOLR-15301
> URL: https://issues.apache.org/jira/browse/SOLR-15301
> Project: Solr
> Issue Type: Improvement
> Components: metrics
> Reporter: Andras Salamon
> Assignee: Andras Salamon
> Priority: Minor
> Fix For: main (9.0)
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> During metrics calculation Solr asks for core indexSize three times. Twice in
> SolrCore and once in ReplicationHandler. It slows down metrics calculation
> and it is also possible that these three reported values are not exactly the
> same if size changes during calculation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
