Re: Sharding configuration

["Ramkumar R. Aiyengar" <an...@gmail.com>]

On 30 Oct 2014 23:46, "Erick Erickson" <er...@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 <an...@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.