lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gora Mohanty <g...@mimirtech.com>
Subject Re: Monitor the QTime.
Date Sat, 12 Feb 2011 09:47:20 GMT
On Sat, Feb 12, 2011 at 3:56 AM, Stijn Vanhoorelbeke
<stijn.vanhoorelbeke@gmail.com> wrote:
>> QTime is, of course, specific to the query, but it is returned in the
>> response XML, so one could run occasional queries to figure it out.
>> Please see http://wiki.apache.org/solr/SearchHandler
>>
>> Regards,
>> Gora
>>
>
> Yes, this could be a possibility. But then the Solr cache jumps back into
> the picture.
> I cannot simply query the system each minute with the same query - that way
> the result would be completely satisfied by the internal caches. I could
> build a list of heavy queries to do so - but I'd loved to use a more
> straight forward method.
[...]

That is true. The time for the first query gives you some idea, but that
is just one measurement, and can be off for various reasons. You can
do drastic things like restarting the Java container each time before
querying. However, one should be thinking of what it is that one is trying
to measure, as the benefits of the various Solr/Lucene caches do matter
in operations:
* If it is the average time for real queries in a running system, the stats
  component gives an idea of that, as someone already pointed out. You
  can access this from the admin at http://localhost:8983/solr/admin/stats.jsp
  (hostname/port might be different for you).
* One could pass randomly generated strings to each query so as to take
  out the effect of caching. I have been meaning to hack pg_bench to do
  this. There is a caveat even here, as a query for a non-existent string is
  likely to be faster.

Regards,
Gora

Mime
View raw message