Hi Christophe, 

Did you find a way to fix up your problem, cuz even with replication will
have this problem, lot of update means clear cache and manage that.
I've the same issue, I just wondering if I won't turn off servers during
update ??? 
How did you fix that ? 

Thanks,
sunny


christophe-2 wrote:
> 
> Hi,
> 
> After fully reloading my index, using another field than a Data does not 
> help that much.
> Using a warmup query avoids having the first request slow, but:
>      - Frequents commits means that the Searcher is reloaded frequently 
> and, as the warmup takes time, the clients must wait.
>      - Having warmup slows down the index process (I guess this is 
> because after a commit, the Searchers are recreated)
> 
> So I'm considering, as suggested,  to have two instances: one for 
> indexing and one for searching.
> I was wondering if there are simple ways to replicate the index in a 
> single Solr server running two cores ? Any such config already tested ? 
> I guess that the standard replication based on rsync can be simplified a 
> lot in this case as the two indexes are on the same server.
> 
> Thanks
> Christophe
> 
> Beniamin Janicki wrote:
>> :so you can send your updates anytime you want, and as long as you only 
>> :commit every 5 minutes (or commit on a master as often as you want, but 
>> :only run snappuller/snapinstaller on your slaves every 5 minutes) your 
>> :results will be at most 5minutes + warming time stale.
>>
>> This is what I do as well ( commits are done once per 5 minutes ). I've
>> got
>> master - slave configuration. Master has turned off all caches (commented
>> in
>> solrconfig.cml) and setup only 2 maxWarmingSearchers. Index size has 5GB
>> ,Xmx= 1GB and committing takes around 10 secs ( on default configuration
>> with warming it took from 30 mins up to 2 hours). 
>>
>> Slave caches are configured to have autowarmCount="0" and
>> maxWarmingSearchers=1 , and I have new data 1 second after snapshoot is
>> done. I haven't noticed any huge delays while serving search request.
>> Try to use those values - may be they'll help in your case too.
>>
>> Ben Janicki
>>
>>
>> -----Original Message-----
>> From: Chris Hostetter [mailto:hossman_luc...@fucit.org] 
>> Sent: 22 October 2008 04:56
>> To: solr-user@lucene.apache.org
>> Subject: Re: Sorting performance
>>
>>
>> : The problem is that I will have hundreds of users doing queries, and a
>> : continuous flow of document coming in.
>> : So a delay in warming up a cache "could" be acceptable if I do it a few
>> times
>> : per day. But not on a too regular basis (right now, the first query
>> that
>> loads
>> : the cache takes 150s).
>> : 
>> : However: I'm not sure why it looks not to be a good idea to update the
>> caches
>>
>> you can refresh the caches automaticly after updating, the "newSearcher" 
>> event is fired whenever a searcher is opened (but before it's used by 
>> clients) so you can configure warming queries for it -- it doesn't have
>> to 
>> be done manually (or by the first user to use that reader)
>>
>> so you can send your updates anytime you want, and as long as you only 
>> commit every 5 minutes (or commit on a master as often as you want, but 
>> only run snappuller/snapinstaller on your slaves every 5 minutes) your 
>> results will be at most 5minutes + warming time stale.
>>
>>
>> -Hoss
>>
>>   
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Sorting-performance-tp20037712p23094174.html
Sent from the Solr - User mailing list archive at Nabble.com.

Reply via email to