1) Single shards have some short circuiting in them. And anyway it's best to have some kind of load balancer in front or use SolrJ with CloudSolrClient. If you just use an HTTP end-point, you have a single point of failure if that node goes down.
2) yes. What it does _not_ include is the time taken to assemble the final document list, i.e. get the "fl" parameters. And also note that there's "the laggard problem" here. The time will be something close to the _longest_ time it takes any replica to respond. Say you have 4 shards and the replica for one of them happens to hit a 5 second stop-the-world GC collection. Your QTime will be 5 seconds+. I really have no idea whether the QTime includes the decision process for selecting nodes, but I've also never heard of it being significant. 3) I guess, although I'm not quite sure I understand the question. Slow queries will include (roughly) the max of the sub-request QTimes. Best, Erick On Sat, Oct 22, 2016 at 5:19 PM, Jay Potharaju <jspothar...@gmail.com> wrote: > Hi, > I am trying to understand how load balancing works in solrcloud. > > As per my understanding solrcloud provides load balancing when querying > using an http endpoint. When a query is sent to any of the nodes , solr > will intelligently decide which server can fulfill the request and will be > processed by one of the nodes in the cluster. > > 1) Does the logic change when there is only 1 shard vs multiple shards? > > 2) Does the QTime displayed is sum of processing time for the query request > + latency(if processed by another node) + time to decide which node will > process the request(which i am guessing is minimal and can be ignored) > > 3) In my solr logs i display the "slow" queries, is the qtime displayed > takes all of the above and shows the correct time taken. > > Solr version: 5.5.0 > > > -- > Thanks > Jay
