Yes, during a commit. I'm planning to do as you suggested, having a master do the indexing and replicating the index to a slave which leads to my next questions. During the slave replicates the index files from the master, how does it impact performance on the slave? Tri
--- On Wed, 1/19/11, Jonathan Rochkind <rochk...@jhu.edu> wrote: From: Jonathan Rochkind <rochk...@jhu.edu> Subject: Re: performance during index switch To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org> Date: Wednesday, January 19, 2011, 11:30 AM During commit? A commit (and especially an optimize) can be expensive in terms of both CPU and RAM as your index grows larger, leaving less CPU for querying, and possibly less RAM which can cause Java GC slowdowns in some cases. A common suggestion is to use Solr replication to seperate out a Solr index that you index to, and then replicate to a slave index that actually serves your queries. This should minimize any performance problems on your 'live' Solr while indexing, although there's still something that has to be done for the actual replication of course. Haven't tried it yet myself. Plan to -- my plan is actually to put them both on the same server (I've only got one), but in seperate JVMs, and on a server with enough CPU cores that hopefully the indexing won't steal CPU the querying needs. On 1/19/2011 2:23 PM, Tri Nguyen wrote: > Hi, > Are there performance issues during the index switch? > As the size of index gets bigger, response time slows down? Are there any >studies on this? > Thanks, > Tri
