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
overhead is smaller than time you get when processing half of index, you
will see increase of TPS. If you are running same query in a loop, first
request will be processed and others will likely be returned from cache,
so response time will not vary with index size hence sharding overhead
will cause TPS to go down.
If you are happy with your response time, and want more TPS, you go with
replications - that will increase number of concurrent requests you can run.
Also, make sure your tests are realistic in order to avoid having false
estimates and have surprises when start running real load.
Regards,
Emir
--
Monitoring * Alerting * Anomaly Detection * Centralized Log Management
Solr & Elasticsearch Support * http://sematext.com/
On 21.12.2015 08:18, Anshul Sharma wrote:
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 scalability, i have done sharding of the same data
across two AWS servers with 2.5 milion records each .When i try to query
the cluster with the same query as before it gives me a tps of ~2500 .
My understanding is the tps should have been increased in a cluster as
these are two different machines which will perform separate I/O operations.
I have not configured any seperate load balancer as the document says that
by default solr cloud will perform load balancing in a round robin fashion.
Can you please help me in understanding the issue.
