Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 23 Oct 2012 20:25:12 +0000 (UTC)
From: "Alan Woodward (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <1776385832.17859.1351023912721.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (SOLR-1972) Need additional query stats in admin
 interface - median, 95th and 99th percentile
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482647#comment-13482647 ] 

Alan Woodward commented on SOLR-1972:
-------------------------------------

Hm, OK.  I'm creating the various Metrics objects in the base class constructor, and registering them by class using this.getClass().  Only problem here is that in a super constructor, getClass() returns the superclass.  Oops.

If I move the object creation to init() I get other errors, because RequestHandlers are registered with JMX before init() is called, and JMX calls getStatistics() to get all the various measurement names and register them.

Maybe put a guard in getStatistics to check if the counters are null, and if they are, instantiate them?  Seems a bit hacky though.  Let me have a think about this.

In re the precision of the measurements, the jscript in the front end could presumably round them to 2 sig figs - that way they look prettier in the UI, but are still precise for any client that wants to use it.
                
> 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
>    Affects Versions: 1.4
>            Reporter: Shawn Heisey
>            Priority: Minor
>         Attachments: elyograg-1972-3.2.patch, elyograg-1972-3.2.patch, elyograg-1972-trunk.patch, elyograg-1972-trunk.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.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972.patch, SOLR-1972-url_pattern.patch
>
>
> 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