Hi,
You are right, it is a mistake in my phrase, for the tests with 4
shards/ 4 instances, the latency was worse (therefore *bigger*) than
for the tests with one shard.
In our case, the query rate is high.
Thanks,
Anca
On 10/30/2014 03:48 PM, Shawn Heisey wrote:
On 10/30/2014 4:32 AM, Anca Kopetz wrote:
We did some tests with 4 shards / 4 different tomcat instances on the
same server and the average latency was smaller than the one when having
only one shard.
We tested also é shards on different servers and the performance results
were also worse.
It seems that the sharding does not make any difference for our index in
terms of latency gains.
That statement is confusing, because if latency goes down, that's good,
not worse.
If you're going to put multiple shards on one server, it should be done
with one solr/tomcat instance, not multiple. One instance is perfectly
capable of dealing with many shards, and has a lot less overhead. The
SolrCloud collection create command would need the maxShardsPerNode
parameter.
In order to see a gain in performance from multiple shards per server,
the server must have a lot of CPUs and the query rate must be fairly
low. If the query rate is high, then all the CPUs will be busy just
handling simultaneous queries, so putting multiple shards per server
will probably slow things down. When query rate is low, multiple CPUs
can handle each shard query simultaneously, speeding up the overall query.
Thanks,
Shawn
Kelkoo SAS
Société par Actions Simplifiée
Au capital de € 4.168.964,30
Siège social : 8, rue du Sentier 75002 Paris
425 093 069 RCS Paris
Ce message et les pièces jointes sont confidentiels et établis à l'attention
exclusive de leurs destinataires. Si vous n'êtes pas le destinataire de ce
message, merci de le détruire et d'en avertir l'expéditeur.
