If possible, it would also be nice to include the change in cache sizes from the beginning to the end of the request. This would help optimize cache sizes for faceting.

thanks

Well, we could provide deltas of all the solr statistics, but I'm not sure if it provides much benefit over watching the stats page before and after executing a query.

What might be more useful if for the facet code to detect facet-cache-thrashing (evictions ~= insertions), and emit a performance warning in the logfile.

A quick version for people to play with. Includes a new timing class, plus timing data inserted into the dismax handler.

Same version with ASF license. Output format looks like:

<lst name="timing">
<double name="debug">13.0</double>
<double name="main query">1.0</double>
<double name="time">19.0</double>
<double name="setup/query parsing">5.0</double>
<double name="pre fetch">0.0</double>
</lst>

(Note that RTimer supports aritrary nesting of timers)

works great for me. thanks!

nesting timers is really nice.

Anyone else have an opinion on timing? It would be easy for me to wrap StandardRequestHandler similarly and commit.

If I add a test or two and put a warning about RTimer being not part of the official solr programmable api, then backward concerns should be limited to the response output. (Otherwise it is likely necessary to think about the design of the RTimer api).

i don't have any strong opinions, but i agree with your plan about putting some warnings in the RTTimer javadocs.

Random thought: it might be cleaner/easier in the long run to create/register a hog Handler that records timing differences and add calls to Logger.entering and Logger.exiting on the various methods.

someone may have already implemented such a Handler

added some average stats to RequestHandlerBase. all of the same info can be obtained by parsing the log files but having it show up on the admin screens and jmx is simple and nice to have. stats added: avgTimePerRequest and avgRequestsPerSecond.

• applies with trunk.
• added timing info to StandardRequestHandler

I think this will make lots of sense in the context of search components:
http://www.nabble.com/search-components-%28plugins%29-tf3898040.html

Might it then make sense to wait until the search component thing is done? Auto-timing everything would be easy.

Will's RequesthandlerBase.patch addition is simple, straightforward, useful - i will add that now.

>
> Might it then make sense to wait until the search component thing is done? Auto-timing everything would be easy.
>

Yes, i think so. but this is still useful for debuging in the meantime. (as a patch)

Will's addition is independent, it adds average timing info to RequestHandler statistics

added javadocs for RTimer.java, and removed a superfluous line from SRH.java

a slightly more ambitious patch that tracks:

• total number of requests/errors
• requests/errors in the current interval (interval defined in solrconfig)
• requets/errors as of the start of the last interval
• avg requet times for total / current interval

Committed as part of SOLR-281