On Sat, Feb 12, 2011 at 3:56 AM, Stijn Vanhoorelbeke <stijn.vanhoorelb...@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
