Hi Aswath,
It is not common to test only QPS unless it is static index most of the
time. Usually you have to test and tune worst case scenario - max
expected indexing rate + queries. You can get more QPS by reducing query
latency or by increasing number of replicas. You manage latency by
tunin
to add to Ericks point:
It's also highly dependent on the types of queries you expect (sorting,
faceting, fq, q, size of documents) and how many concurrent updates you
expect. If most queries are going to be similar and you are not going to be
updating very often, you can expect most of your index
I wouldn't bother to shard either. YMMV of course, but 2.2M documents
is actually a pretty small number unless the docs themselves are huge.
Sharding introduces inevitable overhead, so it's usually the last
thing you resort to.
As far as the number of replicas is concerned, that's strictly a
funct
Hi - we use the Siege load testing program. It can take a seed list of URL's,
taken from actual user input, and can put load in parallel. It won't reuse
common queries unless you prepare your seed list appropriately. If your setup
achieves the goal your client anticipates, then you are fine. Sie
