lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <apa...@elyograg.org>
Subject Re: Solr Query Performance benchmarking
Date Fri, 28 Apr 2017 12:59:07 GMT
On 4/27/2017 5:20 PM, Suresh Pendap wrote:
> Max throughput that I get: 12000 to 12500 reqs/sec
> 95 percentile query latency: 30 to 40 msec

These numbers are *amazing* ... far better than I would have expected to
see on a 27GB index, even in a situation where it fits entirely into
available memory.  I would only expect to see a few hundred requests per
second, maybe as much as several hundred.  Congratulationsare definitely
deserved.

Adding more shards as Toke suggested *might* help, but it might also
lower performance.  More shards means that a single query from the
user's perspective becomes more queries in the background.  Unless you
add servers to the cloud to handle the additional shards, more shards
will usually slow things down on an index with a high query rate.  On
indexes with a very low query rate, more shards on the same hardware is
likely to be faster, because there will be plenty of idle CPU capacity.

What Toke said about filter queries is right on the money.  Uncached
filter queries are pretty expensive.  Once a filter gets cached, it is
SUPER fast ... but if you are constantly changing the filter query, then
it is unlikely that new filters will be cached.

When a particular query does not appear in either the queryResultCache
or the filterCache, running it as a clause on the q parameter will
usually be faster than running it as an fq parameter.  If that exact
query text will be used a LOT, then it makes sense to put it into a
filter, where it will become very fast once it is cached.

Thanks,
Shawn


Mime
View raw message