Return-Path: 
 <solr-user-return-109724-apmail-lucene-solr-user-archive=lucene.apache.org@lucene.apache.org>
X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org
Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 8AFDF17D5E
	for <apmail-lucene-solr-user-archive@minotaur.apache.org>;
 Tue, 17 Mar 2015 20:07:19 +0000 (UTC)
Received: (qmail 23015 invoked by uid 500); 17 Mar 2015 20:07:13 -0000
Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org
Received: (qmail 22947 invoked by uid 500); 17 Mar 2015 20:07:13 -0000
Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:solr-user-help@lucene.apache.org>
List-Unsubscribe: <mailto:solr-user-unsubscribe@lucene.apache.org>
List-Post: <mailto:solr-user@lucene.apache.org>
List-Id: <solr-user.lucene.apache.org>
Reply-To: solr-user@lucene.apache.org
Delivered-To: mailing list solr-user@lucene.apache.org
Received: (qmail 22934 invoked by uid 99); 17 Mar 2015 20:07:12 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Mar 2015 20:07:12 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of apache@elyograg.org designates
 166.70.79.219 as permitted sender)
Received: from [166.70.79.219] (HELO frodo.elyograg.org) (166.70.79.219)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Mar 2015 20:06:48 +0000
Received: from localhost (localhost [127.0.0.1])
	by frodo.elyograg.org (Postfix) with ESMTP id 5DBFDABB0
	for <solr-user@lucene.apache.org>; Tue, 17 Mar 2015 14:06:23 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elyograg.org; h=
	content-transfer-encoding:content-type:content-type:in-reply-to
	:references:subject:subject:mime-version:user-agent:from:from
	:date:date:message-id:received:received; s=mail; t=1426622783;
	 bh=8Vrz15l72W5A25WYPMkc6FvDTV3wYZXn9l8oocJ30Wc=; b=fwyHfucv+pBe
	riQpaccXFSJ0UjpVQfoH0Jtp0+Y+5u3btIuSwHETdL4hlpPJbR5fzxNEvY/hUcWq
	ZXWox1hSJ1zd3upNb72xQjrX+jDAlaQ4p8WnFrgonKeVYtnPyMqm+YMp4q+MPuYt
	BsSF3d3FPNlEYc0O1Mt5AoHYDAvsLFw=
X-Virus-Scanned: Debian amavisd-new at frodo.elyograg.org
Received: from frodo.elyograg.org ([127.0.0.1])
	by localhost (frodo.elyograg.org [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id U7QreH70Zs2u for <solr-user@lucene.apache.org>;
	Tue, 17 Mar 2015 14:06:23 -0600 (MDT)
Received: from [192.168.1.102] (102.int.elyograg.org [192.168.1.102])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	(Authenticated sender: elyograg@elyograg.org)
	by frodo.elyograg.org (Postfix) with ESMTPSA id 046BBAAA5
	for <solr-user@lucene.apache.org>; Tue, 17 Mar 2015 14:06:23 -0600 (MDT)
Message-ID: <55088949.2030502@elyograg.org>
Date: Tue, 17 Mar 2015 14:06:33 -0600
From: Shawn Heisey <apache@elyograg.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: solr-user@lucene.apache.org
Subject: Re: When does SolrJ client add isShard=true automatically to the
 query
References: <1426610165895-4193512.post@n3.nabble.com>
In-Reply-To: <1426610165895-4193512.post@n3.nabble.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

On 3/17/2015 10:36 AM, pramodEbay wrote:
> We are using 3 shard solr cloud with 5 replicas per shard. We use SolrJ to
> execute solr queries. Often times, I cannot explain when, but we see in the
> query, isShard=true and shard.url=<ip addresses of all the replicas>. 
> 
> My questions are, 
> 
> 1. Why does this happen intermittently 
> 2. When this happens, will it send requests to all the replicas in the shard
> and slow us down.
> 3. Most importantly, how can we avoid this situation. 
> 
> We also use zookeeper to manage our cluster. I am concerned that, if we add
> more replicas to each shard, this query will become slower.

The requests from your SolrJ client do NOT have isShard=true.

>From there, because your index is distributed (it has three shards),
Solr itself will send sub-requests that have isShard=true to the other
nodes, collect the information to determine the final result set, then
send ANOTHER request to each of the shards to collect the actual results.

The nodes (replicas) that SolrCloud will use to fulfill the distributed
request are chosen at random.  Queries are not likely to slow down if
you add replicas, unless you are not adding additional hardware.  If you
are adding additional hardware, they may in fact get faster.  Indexing
may slow down a little bit.

Thanks,
Shawn