lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Trivial Update of "SolrCaching" by MartijnKoster
Date Sun, 31 Oct 2010 16:01:34 GMT
Dear Wiki user,

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

The "SolrCaching" page has been changed by MartijnKoster.
The comment on this change is: some typos.
http://wiki.apache.org/solr/SolrCaching?action=diff&rev1=21&rev2=22

--------------------------------------------------

  The initial capacity (number of entries) of the cache.  (see `java.util.HashMap`)
  
  == autowarmCount ==
- The number of entries to prepopulate from and old cache.
+ The number of entries to prepopulate from an old cache.
  
  When a new searcher is opened, its caches may be prepopulated or "autowarmed" with cached
object from caches in the old searcher. autowarmCount is the number of cached items that will
be regenerated in the new searcher. You will proably want to base the autowarmCount setting
on how long it takes to autowarm. You must consider the trade-off — time-to-autowarm versus
how warm (i.e., autowarmCount) you want the cache to be. The autowarm parameter is set for
the caches in solrconfig.xml.
  
- <!> [[Solr4.0]] autowarmCount can now be specified as a percentage (ie: "90%") which
will be evaluated relative the number of items in the existing cache.  This can be an advantageous
setting in an instance of Solr where you don't expect any search traffic (ie a master), but
you want some caches so that if it does take on traffic it won't be too overloaded.  Once
the traffic dies down, subsequent commits will gradually decrease the number of items being
warmed.
+ <!> [[Solr4.0]] autowarmCount can now be specified as a percentage (ie: "90%") which
will be evaluated relative to the number of items in the existing cache.  This can be an advantageous
setting in an instance of Solr where you don't expect any search traffic (ie a master), but
you want some caches so that if it does take on traffic it won't be too overloaded.  Once
the traffic dies down, subsequent commits will gradually decrease the number of items being
warmed.
  
  == minSize (optional) ==
  Only applicable for `FastLRUCache` . After the cache reaches its size, the cache tries to
bring it down to the `minSize`. The default value is `0.9 * size` .
@@ -93, +93 @@

  
  The size for the documentCache should always be greater than <max_results> * <max_concurrent_queries>,
to ensure that Solr does not need to refetch a document during a request. The more fields
you store in your documents, the higher the memory usage of this cache will be.
  
- Each Document object in the documentCache contains a List of Field references.  When enableLazyFieldLoading=true
is set, and there is a documentCache, Document objects fetched from the IndexReader will only
contain the Fields specified in the fl. All other Fields will be marked as "LOAD_LAZY". When
there is a cache hit on that uniqueKey at a later date, the Fields allready loaded are used
directly (if requested), but the Fields marked LOAD_LAZY will lazy loaded from the IndexReader
and then the Document object updates the references to the newly actualized fields (which
are no longer marked LOAD_LAZY). So with different "fl" params, the same Document Object can
be re-used from the documentCache, but the Fields in that Document grow as the fields requested
(using the "fl" param) change.
+ Each Document object in the documentCache contains a List of Field references.  When enableLazyFieldLoading=true
is set, and there is a documentCache, Document objects fetched from the IndexReader will only
contain the Fields specified in the fl. All other Fields will be marked as "LOAD_LAZY". When
there is a cache hit on that uniqueKey at a later date, the Fields allready loaded are used
directly (if requested), but the Fields marked LOAD_LAZY will be lazy loaded from the IndexReader
and then the Document object updates the references to the newly actualized fields (which
are no longer marked LOAD_LAZY). So with different "fl" params, the same Document Object can
be re-used from the documentCache, but the Fields in that Document grow as the fields requested
(using the "fl" param) change.
  
  ''(Note: This cache cannot be used as a source for autowarming because document IDs will
change when anything in the index changes so they can't be used by a new searcher.)''
  
@@ -195, +195 @@

      -->
      <HashDocSet maxSize="3000" loadFactor="0.75"/>
  }}}
- The hashDocSet max size should be based primarliy on the number of documents in the collection—the
larger the number of documents, the larger the hashDocSet max size. You will have to do a
bit of trial-and-error to arrive at the optimal number:
+ The hashDocSet max size should be based primarily on the number of documents in the collection—the
larger the number of documents, the larger the hashDocSet max size. You will have to do a
bit of trial-and-error to arrive at the optimal number:
  
-  1. Calulate 0.005 of the total number of documents that you are going to store.
+  1. Calculate 0.005 of the total number of documents that you are going to store.
   1. Try values on either 'side' of that value to arrive at the best query times.
   1. When query times seem to plateau, and performance doesn't show much difference between
the higher number and the lower, use the higher.
  

Mime
View raw message