[
https://issues.apache.org/jira/browse/SOLR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13541903#comment-13541903
]
Shawn Heisey edited comment on SOLR-1972 at 1/1/13 7:51 PM:
------------------------------------------------------------
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, and it conveniently contains a place where
all request handlers get registered. 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.
was (Author: elyograg):
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: 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,
> 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_forked-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,
> 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
