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
tuning Solr/JVM/queries and/or by sharding index. You first tune index
without replication and when sure it is best single index can provide,
you introduce replicas to achieve required throughput.
Hard part is tuning Solr. You can do it without specialized tools, but
tools help a lot. One such tool is Sematext's SPM -
https://sematext.com/spm/index.html where you can see all necessary
Solr/JVM/OS metrics needed to tune Solr. It also provides QPS graph.
With index your size, unless documents are really big, you can start
without sharding. After tuning, if not satisfied with query latency, you
can try splitting to two shards.
Thanks,
Emir
--
Monitoring * Alerting * Anomaly Detection * Centralized Log Management
Solr & Elasticsearch Support * http://sematext.com/
On 17.11.2015 23:45, Aswath Srinivasan (TMS) wrote:
Hi fellow developers,
Please share your experience, on how you did performance testing on SOLR? What
I'm trying to do is have SOLR cloud on 3 Linux servers with 16 GB RAM and index
a total of 2.2 million. Yet to decide how many shards and replicas to have (Any
hint on this is welcome too, basically 'only' performance testing, so suggest
the number of shards and replicas if you can). Ultimately, I'm trying to find
the QPS that this SOLR cloud set up can handle.
To summarize,
1. Find the QPS that my solr cloud set up can support
2. Using 5.3.1 version with external zookeeper
3. 3 Linux servers with 16 GB RAM and index a total of 2.2 million documents
4. Yet to decide number of shards and replicas
5. Not using any custom search application (performance testing for SOLR and
not for Search portal)
Thank you
