lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walter Underwood <wun...@wunderwood.org>
Subject Re: Solr Query Performance benchmarking
Date Fri, 28 Apr 2017 14:43:19 GMT
More “unrealistic” than “amazing”. I bet the set of test queries is smaller than the
query result cache size.

Results from cache are about 2 ms, but network communication to the shards would add enough
overhead to reach 40 ms.

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Apr 28, 2017, at 5:59 AM, Shawn Heisey <apache@elyograg.org> wrote:
> 
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message