t;> > Thanks
>>> > Dipti
>>> >
>>> >
>>> > On Fri, Jan 22, 2010 at 10:36 AM, Otis Gospodnetic <
>>> > otis_gospodne...@yahoo.com> wrote:
>>> >
>>> > > Dipti,
>>> > >
>>> >
zing the index on the
>> master
>> > > before replicating it?
>> > > There is no need to do that if you are constantly updating your index
>> and
>> > > replicating it every 10 minutes.
>> > > Don't optimize, and you'll repli
o need to do that if you are constantly updating your index
> and
> > > replicating it every 10 minutes.
> > > Don't optimize, and you'll replicate smaller portion of an index, and
> > thus
> > > you won't bust the OS cache on the slave
ll see further benefits from faster
> > searcher warmup times.
> >
> > Otis
> > --
> > Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch
> >
> >
> >
> > - Original Message
> > > From: dipti khullar
> > >
is
> --
> Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch
>
>
>
> - Original Message
> > From: dipti khullar
> > To: solr-user@lucene.apache.org
> > Sent: Thu, January 21, 2010 11:48:20 AM
> > Subject: Re: Improvising solr queries
> >
> &g
r-user@lucene.apache.org
> Sent: Thu, January 21, 2010 11:48:20 AM
> Subject: Re: Improvising solr queries
>
> Hi
>
> Sorry for getting back late on the thread, but we are focusing on
> configuration of master and slave for improving performance issues.
>
> We have obser
What this looks like (and I've only glanced) is that your
index updates are causing a new searcher to
be opened, and the first few queries after
the reopen will be slow.
Have you tried warmup queries after the reopen?
FWIW
Erick
On Thu, Jan 21, 2010 at 11:48 AM, dipti khullar wrote:
> Hi
>
> So
Hi
Sorry for getting back late on the thread, but we are focusing on
configuration of master and slave for improving performance issues.
We have observed following trend on production slaves:
After every 10 minutes the response time increases considerably. In between
all the queries are served by
On Tue, Jan 5, 2010 at 11:16 AM, dipti khullar wrote:
>
> This assettype is variable. It can have around 6 values at a time.
> But this is true that we apply facet mostly on just one field - assettype.
>
>
Ian has a good point. You are faceting on assettype and you are also
filtering on it so you
Hey Ian
This assettype is variable. It can have around 6 values at a time.
But this is true that we apply facet mostly on just one field - assettype.
Any idea if the use of date range queries is expensive? Also if Shalin can
put in some comments on
"sorting by date was pretty rough on CPU", I can
On 1/5/10 12:46 AM, Shalin Shekhar Mangar wrote:
sitename:XYZ OR sitename:"All Sites") AND (localeid:1237400589415) AND
> ((assettype:Gallery)) AND (rbcategory:"ABC XYZ" ) AND (startdate:[* TO
> 2009-12-07T23:59:00Z] AND enddate:[2009-12-07T00:00:00Z TO
> *])&rows=9&start=63&sort=date
> desc
Hi -
Something doesn't make sense to me here:
On Mon, Jan 4, 2010 at 5:55 AM, dipti khullar wrote:
> - optimize runs on master in every 7 minutes
> - using postOptimize , we execute snapshooter on master
> - snappuller/snapinstaller on 2 slaves runs after every 10 minutes
>
>
Why would you optim
On Mon, Jan 4, 2010 at 7:25 PM, dipti khullar wrote:
> Thanks Shalin.
>
> Following are the relevant details:
>
> There are 2 search servers in a virtualized VMware environment. Each has 2
> instances of Solr running on separates ports in tomcat.
> Server 1: hosts 1 master(application 1), 1 slave
On Mon, Jan 4, 2010 at 6:39 PM, dipti khullar wrote:
> We have tried out various configurations settings to improvise the
> performance of the site which is majorly using Solr but still the response
> time remains about 4-5 reqs/sec. We also did some performance tests on Solr
> 1.4 but still there
Hi
We have tried out various configurations settings to improvise the
performance of the site which is majorly using Solr but still the response
time remains about 4-5 reqs/sec. We also did some performance tests on Solr
1.4 but still there is a very minute improvement in performance. Currently
we
15 matches
Mail list logo
