As I am not running queries in parallel every query is handled by a single
CPU, I didn't see any benefit from splitting it to less shards. More to it,
while running load tests on a single shard I could see I was CPU bounded
and got much better performances by splitting the index to many shards,
whi
Please send Solr-related inquiries to the Solr user list - this is the
Lucene (Java) user list.
-- Jack Krupansky
-Original Message-
From: Manuel Le Normand
Sent: Sunday, September 08, 2013 7:03 AM
To: java-user@lucene.apache.org
Subject: Profiling Solr Lucene for query
Hello all
Why have 36 shards for just a few million docs each? That's the first thing
I'd
look at. How many physical boxes? How much memory per JVM? How
many JVMs? How much physical memory per box?
'Cause this seems excessive time-wise for loading the info.
Best
Erick
On Sun, Sep 8, 2013 at 7:03 AM,
Hello all
Looking on the 10% slowest queries, I get very bad performances (~60 sec
per query).
These queries have lots of conditions on my main field (more than a
hundred), including phrase queries and rows=1000. I do return only id's
though.
I can quite firmly say that this bad performance is due
