lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <>
Subject [jira] [Updated] (SOLR-1972) Need additional query stats in admin interface - median, 95th and 99th percentile
Date Tue, 01 Jan 2013 19:42:13 GMT


Shawn Heisey updated SOLR-1972:

    Attachment: elyograg-closeable.patch

elyograg-closeable.patch - my attempt at fixing problems.

Explicitly uses default registry, includes close() method that removes metrics from the default
registry.  Sprinkles Closeable around a bit.  Turns out it was easier than expected to find
places to close() request handlers -- SolrCore already includes a close() method.  I did my
best to search in eclipse to make sure I didn't miss something.

Initially I tried to put "prev.close();" into SolrCore#reload, but that caused test failures.
 I was able to determine that only CoreContainer#reload currently calls SolrCore#reload, so
I now close the old core there, after it registers the new core.

All tests pass, but I think it would be a good idea to create a test that checks for the thread
leak.  I don't know if this implementation will solve that problem or not with metrics-core
2.2.0, but I am hopeful.

I double-checked my implementation with metrics-core 3.0.0-SNAPSHOT.  It will require some
method name tweaks, but otherwise it is compatible.

This patch leaves the ThreadLeakFilter that Robert indicated was ridiculous.
> Need additional query stats in admin interface - median, 95th and 99th percentile
> ---------------------------------------------------------------------------------
>                 Key: SOLR-1972
>                 URL:
>             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, elyograg-closeable.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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message