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
