lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Taylor <paul_t...@fastmail.fm>
Subject Re: In Lucene 3.5 is it always better to not optimize indexes ?
Date Fri, 02 Mar 2012 19:26:23 GMT
On 02/03/2012 18:58, Uwe Schindler wrote:
> Why not simply forceMerge your index one time and compare with unoptimized?
Well its not straightforward for me to do that as the problem is only 
rearing its head on Production, and I don't have access to the 
Production machine.

Paul
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>> -----Original Message-----
>> From: Paul Taylor [mailto:paul_t100@fastmail.fm]
>> Sent: Friday, March 02, 2012 6:08 PM
>> To: java-user@lucene.apache.org
>> Subject: In Lucene 3.5 is it always better to not optimize indexes ?
>>
>> I've updated codebase from 3.4 to 3.5 and as part of that took the advice
> to no
>> longer optimize my indexes.
>>
>> During testing everything seemed okay but since releasing to Live noticed
> the
>> load on the servers is about 50% higher. I made quite a few code changes
> in
>> this release but its not obvious that these would cause this increase so
> Im
>> wondering if maybe the problem is
>>
>> 1. My searches are now working off unoptimized indexes rather than
> optimized
>> indexes ?
>> 2. 3.5 is slower than 3.4
>> 3. The number of documents in each index is the same but I added two new
>> fields so the size of each index is about 20% larger, does this have much
> effect
>> ?
>>
>> Paul
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message