On 30 Oct 2014 23:46, "Erick Erickson" <erickerick...@gmail.com> wrote: > > This configuration deals with all > the replication, NRT processing, self-repair when nodes go up and > down and all that, but since there's no second trip to get the docs > from shards your query performance won't be affected.
More or less.. Vaguely recall that you still would need to add a shortCircuit parameter to the url in such a case to avoid a second trip. I might be wrong here but I do recall wondering why that wasn't the default.. > > And using SolrCloud with a single shard will essentially scale linearly > as you add nodes for queries. > > Best, > Erick > > > On Thu, Oct 30, 2014 at 8:29 AM, Anca Kopetz <anca.kop...@kelkoo.com> wrote: > > 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.
