You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Alan Woodward (JIRA)" <ji...@apache.org> on 2013/01/01 16:34:14 UTC
[jira] [Comment Edited] (SOLR-1972) Need additional query stats in
admin interface - median, 95th and 99th percentile
[ https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541647#comment-13541647 ]
Alan Woodward edited comment on SOLR-1972 at 1/1/13 3:32 PM:
-------------------------------------------------------------
Cleaning this up is not looking as easy as I had thought, unfortunately. The leaky metrics tick threads have been removed in metrics trunk, but that change isn't in any released version yet. I'll try doing what Lance suggested, and just copy the relevant classes. I *think* I can then do away with the registry entirely, and just make the Counter and Timer objects final members of RequestHandlerBase. Then we don't get any interned strings or timer threads, but we keep all the nice exponential-decay stats code.
Metrics is apache 2.0 licensed, so I think I'm OK to just copy classes over?
was (Author: romseygeek):
Cleaning this up is not looking as easy as I had thought, unfortunately. The leaky metrics tick threads have been removed in metrics trunk, but that change isn't in any released version yet. I'll try doing what Lance suggested, and just copy the relevant classes. I *think* I can then do away with the registry entirely, and just make the Counter and Timer objects final members of RequestHandlerBase. Then we don't get any interned strings or timer threads, but we keep all the nice exponential-decay stats code.
Metrics is apache 2.0 licenses, so I think I'm OK to just copy classes over?
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org