[
https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541453#comment-13541453
]
Shawn Heisey commented on SOLR-1972:
------------------------------------
Alan, my latest plan still utilized the global registry, though it did it
explicitly, so that individual metric objects were removed by a close() method
on RequestHandlerBase. That would have required many changes - finding every
place that a handler might be deleted or replaced. That likely would require
significant refactoring rather than just a few code edits. I was prepared to
do it, if someone could light the path.
An explicit registry per core is an awesome idea, if it can be implemented
without similar pain to what I've just described. Looking at
RequestHandlerBase, I don't see any direct way to access the containing core
object. Experimentation shows that adding a constructor with a SolrCore
argument is not the right approach because it would require *a lot* of changes
that are also likely to break custom user code.
> Need additional query stats in admin interface - median, 95th and 99th
> percentile
> ---------------------------------------------------------------------------------
>
> Key: SOLR-1972
> URL: https://issues.apache.org/jira/browse/SOLR-1972
> Project: Solr
> Issue Type: Improvement
> Components: web gui
> Affects Versions: 1.4
> Reporter: Shawn Heisey
> Assignee: Alan Woodward
> Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch,
> elyograg-1972-trunk.patch, elyograg-1972-trunk.patch, leak-closeable.patch,
> leak.patch, revert-SOLR-1972.patch, SOLR-1972-branch3x-url_pattern.patch,
> SOLR-1972-branch4x.patch, SOLR-1972-branch4x.patch, SOLR-1972_metrics.patch,
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch,
> SOLR-1972_metrics.patch, SOLR-1972_metrics.patch, SOLR-1972_metrics.patch,
> SOLR-1972_metrics.patch, solr1972-metricsregistry-branch4x-failure.log,
> SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch,
> SOLR-1972-url_pattern.patch, stacktraces.tar.gz
>
>
> I would like to see more detailed query statistics from the admin GUI. This
> is what you can get now:
> requests : 809
> errors : 0
> timeouts : 0
> totalTime : 70053
> avgTimePerRequest : 86.59209
> avgRequestsPerSecond : 0.8148785
> I'd like to see more data on the time per request - median, 95th percentile,
> 99th percentile, and any other statistical function that makes sense to
> include. In my environment, the first bunch of queries after startup tend to
> take several seconds each. I find that the average value tends to be useless
> until it has several thousand queries under its belt and the caches are
> thoroughly warmed. The statistical functions I have mentioned would quickly
> eliminate the influence of those initial slow queries.
> The system will have to store individual data about each query. I don't know
> if this is something Solr does already. It would be nice to have a
> configurable count of how many of the most recent data points are kept, to
> control the amount of memory the feature uses. The default value could be
> something like 1024 or 4096.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
