[Solr Wiki] Trivial Update of "SolrCaching" by MartijnKoster

[Apache Wiki <wi...@apache.org>]

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.