: The easiest way is to run maybe 100,000 or more queries and take an
: average. A single microsecond value for a query would be incredibly
: inaccurate.
that can be useful for doing the timing externally, if you're interested
in averaging over all X queries in a sequential batch, but it doesn't help
with things like replaying a live log (so you see acurate cache
behavior) and then trying to evaluate wether a subset of those queries
(the ones that use faceting maybe) are faster with config X then with
config Y .. for that you really want to be able to crunch the logs to
extract just hte requests you are interested in and then generate stats --
but as Ahmet points out, with millisecond resolution soemthing that takes
about 1 millisecond is hard to profile for possible improvements.
with the Solr code as written the best suggestion i can make is to see if
your servlet container can log it's requests at microsecond resolution --
that will include the ResponseWriter timing and the network overhead, but
that may better anyway.
A patch to change Solr to use System.nanoTime() for all the internal
timein would probably be pretty straight forward -- we'd just have to
consider wether it will screw people up if we change the format that gets
logged or included in teh response.
-Hoss