have too many documents.
> > > > Perhaps you want replication instead of sharding for improved
> > > > performance.
> > > > Personal website: http://www.outerthoughts.com/
> > > > LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
>
gt; > > - Time is the quality of nature that keeps events from happening all
> > > at once. Lately, it doesn't seem to be working. (Anonymous - via GTD
> > > book)
> > >
> > >
> > > On Wed, Feb 5, 2014 at 6:31 AM, Alexey Kozhemiakin
&g
> > wrote:
> > > Btw "timing" for distributed requests are broken at this moment, it
> > doesn't combine values from requests to shards. I'm working on a patch.
> > >
> > > https://issues.apache.org/jira/browse/SOLR-3644
> > >
>
s from requests to shards. I'm working on a patch.
> >
> > https://issues.apache.org/jira/browse/SOLR-3644
> >
> > -Original Message-
> > From: Jack Krupansky [mailto:j...@basetechnology.com]
> > Sent: Tuesday, February 04, 2014 22:00
> > T
wse/SOLR-3644
>
> -Original Message-
> From: Jack Krupansky [mailto:j...@basetechnology.com]
> Sent: Tuesday, February 04, 2014 22:00
> To: solr-user@lucene.apache.org
> Subject: Re: Lowering query time
>
> Add the debug=true parameter to some test queries and
t: Tuesday, February 04, 2014 22:00
To: solr-user@lucene.apache.org
Subject: Re: Lowering query time
Add the debug=true parameter to some test queries and look at the "timing"
section to see which search components are taking the time. Traditionally,
highlighting for large documen
. Traditionally,
> highlighting for large documents was a top culprit.
>
> Are you returning a lot of data or field values? Sometimes reducing the
> amount of data processed can help. Any multivalued fields with lots of
> values?
>
> -- Jack Krupansky
>
> -Original M
nt of data processed can help. Any multivalued fields with lots of
values?
-- Jack Krupansky
-Original Message-
From: Joel Cohen
Sent: Tuesday, February 4, 2014 1:43 PM
To: solr-user@lucene.apache.org
Subject: Re: Lowering query time
1. We are faceting. I'm not a developer so I'
On Tue, Feb 4, 2014 at 1:43 PM, Joel Cohen wrote:
> 1. We are faceting. I'm not a developer so I'm not quite sure how we're
> doing it. How can I measure?
Add debugQuery=true to the request and look at the timings of various
components.
> 2. I'm not sure how we'd force this kind of document part
1. We are faceting. I'm not a developer so I'm not quite sure how we're
doing it. How can I measure?
2. I'm not sure how we'd force this kind of document partitioning. I can
see how my shards are partitioned by looking at the clusterstate.json from
Zookeeper, but I don't have a clue on how to get d
On Tue, Feb 4, 2014 at 12:12 PM, Joel Cohen wrote:
> I'm trying to get the query time down to ~15 msec. Anyone have any tuning
> recommendations?
I guess it depends on what the slowest part of the query currently is.
If you are faceting, it's often that.
Also, it's often a big win if you can som
Hi all,
I'm on my way to migrating from a proprietary search technology (Endeca) to
SolrCloud 4.6.1.
I'm running 4 servers with 8 cores (2 threads per core with hyperthreading)
and 64 Gb of RAM per server. Each server has 4 shards and each shard is
running in a separate Tomcat instance with a 4 G
12 matches
Mail list logo
