How many documents do you have? How big is the index?
You can increase total throughput with replicas. Shards will make it slower,
but allow more documents.
At 8000 queries/s, I assume you are using the same query over and over. If so,
that is a terrible benchmark. Everything is served out of c
You add shards to reduce response times. If your responses are too slow
for 1 shard, try it with three. Skip two for reasons stated above.
Upayavira
On Mon, Dec 21, 2015, at 04:27 PM, Erick Erickson wrote:
> 8,000 TPS almost certainly means you're firing the same (or
> same few) requests over an
8,000 TPS almost certainly means you're firing the same (or
same few) requests over and over and hitting the queryResultCache,
look in the adminUI>>core>>plugins/stats>>cache>>queryResultCache.
I bet you're seeing a hit ratio near 100%. This is what Toke means
when he says your tests are too lightw
Hi Anshul,
TPS depends on number of concurrent request you can run and request
processing time. With sharding you reduce processing time with reducing
amount of data single node process, but you have overhead of inter shard
communication and merging results from different shards. If that
overh
Anshul Sharma wrote:
> I have configured solr on 1 AWS server as standalone application which is
> giving me a tps of ~8000 for my query.
[...]
> In order to test the scalability, i have done sharding of the same data
> across two AWS servers with 2.5 milion records each .When i try to query
> t
Hi,
I am trying to evaluate solr for one of my project for which i need to
check the scalability in terms of tps(transaction per second) for my
application.
I have configured solr on 1 AWS server as standalone application which is
giving me a tps of ~8000 for my query.
In order to test the scalabil
