On 30 Oct 2014 14:49, "Shawn Heisey" wrote:
> 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 pu
On 30 Oct 2014 23:46, "Erick Erickson" 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.. Vagu
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 do
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 K
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
Hi,
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 an
eaded
applications" 2013.
FYI:
-Original Message-
From: Ramkumar R. Aiyengar [mailto:andyetitmo...@gmail.com]
Sent: Tuesday, October 28, 2014 3:44 PM
To: solr-user@lucene.apache.org
Subject: Re: Sharding configuration
As far as the second option goes, unless you a
As far as the second option goes, unless you are using a large amount of
memory and you reach a point where a JVM can't sensibly deal with a GC
load, having multiple JVMs wouldn't buy you much. With a 26GB index, you
probably haven't reached that point. There are also other shared resources
at an i
