This is not too surprising. There are additional hops necessary for a cloud setup. This is the sequence, let's say there are 4 shards and the rows parameter on the query is 10 and you're sorting by score
node1 receives request. node1 sends the request out to each shard node1 receives the top 10 doc Ids back with the score (note, not the _contents_). node1 sorts the 4 lists of 10 docs into the final top 10. node1 then requests the actual docs from the nodes that they reside on node1 then gets the results back and assembles them into a final list node1 then returns the list to the client. Contrast this with a single shard node1 receives the request node1 finds the top 10 docs locally node1 return the docs to the client You should only resort to sharding when you have too many docs to fit in a single shard (and give you acceptable search times). If all your docs fit comfortably on a single machine, you can _still_ use SolrCloud, just with a single shard. 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. 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.
