Hello,
1. It depends on your query types & data (complexity, featureset,
paging) - geospatial could be something with calculation inside solr?
2. It depends massively on the document size & field-selection (load a
hundred of 100MB documents can take some time)
3. It depends especially on your disc IO / Ram utilization - are these
dedicated machines ?
4. It depends on how often you changing your documents (cache
warm-ups!!!, disc IO)!
5. What is the bottleneck? CPU ? RAM ? Disc? You should be able to give
some more information about this.
6. It depends on the amount of cores (more cores must not be better -
CPU-caching, OS-management overhead...)
7. Force cache hit-rate - means: control the type of queries, cluster
them and send them to A or B - to have a higher chance for a cache hit.
Maybe you can give some more details about the points I mentioned.
Ralf
On 07/16/2013 04:42 PM, adfel70 wrote:
Hi
I need to create a solr cluster that contains geospatial information and
provides the ability to perform a few hundreds queries per second, each
query should retrieve around 100k results.
The data is around 100k documents, around 300gb total.
I started with 2 shard cluster (replicationFactor 1) and a portion of the
data - 20 gb.
I run some load-tests and see that when 100 requests are sent in one second,
the average qTime is around 4 seconds, but the average total response time
(measuring from sending the request to solr untill getting a response )
reaches 20-25 seconds which is very bad.
Currently I load-balance myself between the 2 solr servers (each request is
sent to another server)
Any advice on which resources do I need and how my solr cluster should look
like?
More shards? more replicas? another webserver?
Thanks.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Need-advice-on-performing-300-queries-per-second-on-solr-index-tp4078353.html
Sent from the Solr - User mailing list archive at Nabble.com.
