Mailing-List: contact solr-commits-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Thu, 03 Nov 2011 23:26:12 -0000
Message-ID: <20111103232612.64519.76402@eos.apache.org>
Subject: 
 =?utf-8?q?=5BSolr_Wiki=5D_Update_of_=22SolrPerformanceFactors=22_by_Rober?=
 =?utf-8?q?tMuir?=
Auto-Submitted: auto-generated

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for chan=
ge notification.

The "SolrPerformanceFactors" page has been changed by RobertMuir:
http://wiki.apache.org/solr/SolrPerformanceFactors?action=3Ddiff&rev1=3D28&=
rev2=3D29

Comment:
die optimize die

  =

     * Memory usage during indexing
     * Segment merge time
-    * Optimization times
     * Index size
  =

  These impacts can be reduced by the use of `omitNorms=3D"true"`
@@ -74, +73 @@

  =3D=3D=3D Explicit Warming of Sort Fields =3D=3D=3D
  =

  If you do a lot of field based sorting, it is advantageous to add explici=
tly warming queries to the "newSearcher" and "firstSearcher" event listener=
s in your solrconfig which sort on those fields, so the !FieldCache is popu=
lated prior to any queries being executed by your users.
- =

- =3D=3D Optimization Considerations =3D=3D
- =

- You may want to optimize an index whenever practical -- ie: if you build =
your index once, and then never modify it.
- =

- If your index is receiving a steady stream of modifications, then conside=
r the following factors...
- =

-    * As more segments are added to the index, query performace will degra=
de slightly.  Automatic segment merging by Lucene will set an upper bound o=
n the number of segments created though.
-    * Auto-warming time will grow since it's normally dependent on doing s=
earches. =

-    * The first distribution after an optimization will take longer than s=
ubsequent ones. See [[CollectionDistribution|Collection Distribution]] for =
more information.
-    * During optimization the file size of the index doubles, but returns =
to it's original size or even slightly less.
-    * If you can, make sure that you do not have multiple concurrent produ=
cers of documents calling commit(). Multiple concurrent commits will cause =
a large performance degradation. =

- =

- Since optimizing an index saves all the segments in an index (about 7 fil=
es per segment) into a single segment, optimizing an index helps avoid the =
"too many open files" problem, i.e. running out of file descriptors, which =
is mentioned in an [[http://www.onjava.com/pub/a/onjava/2003/03/05/lucene.h=
tml#indexing_speed|ONJava Article]].
  =

  =3D=3D Updates and Commit Frequency Tradeoffs =3D=3D
 =20