Hi Erick,
Up to now, all the tests were based on randomly generated requests.
In reality, many requests will get executed more than twice since this is to
support the advertising project. On the other hand, new queries could be
generated daily. So some of the filter queries will be used frequent
Well, It Depends (tm). I've certainly seen response times on that order, it all
revolves around the complexity of the queries, how much faceting you're
doing, all that kind of thing.
If always specifying cache=false works for you, go for it. The only caution I
would add is that randomly generating
Hi Erick,
The earlier test was done through individual requests. However, my load test
is even better.
(1) load test (3 requests/per second/per core) immediately after restarting
Solr: average response time: 122 ms
(2) load test (5 requests/per second/per core) immediately after restarting
Solr:
bq: Does that make sense?
In a word, yes. Without {!cache=false}, each and
every document in the entire corpus is examined
and a bitset constructed that represents that
result set, then the entry in the filter cache is
constructed.
With cache=false, only docs that make it through the
rest of the
