indexed fields
indexed fields 的數量將會影響以下的一些性能：
- 索引時的時候的內存使用量
- 索引段的合并時間
- 優化時間
- 索引的大小
我們可以通過 將 omitNorms=“true” 來減少indexed fields數量增加所帶來的影響。
stored fields
Retrieving the stored fields 確實是一種開銷。這個開銷，受每個文檔所存儲的字節影響很大。每個文檔的所占用的空間越大，文檔就顯的更稀疏，這樣從硬盤中讀取數據，就需要更多的i/o操作（通常，我們在存儲比較大的域的時候，就會考慮這樣的事情，比如存儲一篇文章的文檔。）
可以考慮將比較大的域放到solr外面來存儲。如果你覺得這樣做會有些別扭的話，可以考慮使用壓縮的域，但是這樣會加重cpu在存儲和讀取域的時候的負擔。不過這樣卻是可以較少i/0的負擔。
如果，你并不是總是使用 stored fields 的話，可以使用stored field的延遲加載，這樣可以節省很多的性能，尤其是使用compressed field 的時候。
Configuration Considerations
mergeFactor
這個是合并因子，這個參數大概決定了segment(索引段)的數量。
合并因子這個值告訴lucene，在什么時候，要將幾個segment合并成為一個segment, 合并因子就像是一個數字系統的基數一樣。
比如說，如果你將合并因子設成10，那么每往索引中添加1000個文檔的時候，就會創建一個新的索引段。當第10個大小為1000的索引段添加進來的時候，這十個索引段就會被合并成一個大小為10，000的索引段。當十個大小為10，000的索引段生成的時候，它們就會被合并成一個大小為100，000 的索引段。如此類推下去。
這個值可以在 solrconfig.xml 中的 *mainIndex*中設置。（不用管indexDefaults中設置）
mergeFactor Tradeoffs
較高的合并因子
- 會提高索引速度
- 較低頻率的合并，會導致 更多的索引文件，這會降低索引的搜索效率
較低的合并因子
- 較少數量的索引文件，能加快索引的搜索速度。
- 較高頻率的合并，會降低索引的速度。
Cache autoWarm Count Considerations
當一個新的 searcher 打開的時候，它緩存可以被預熱，或者說使用從舊的searcher的緩存的數據來“自動加熱”。autowarmCount是這樣的一個參數，它表示從舊緩存中拷貝到新緩存中的對象數量。autowarmCount這個參數將會影響“自動預熱”的時間。有些時候，我們需要一些折中的考慮，seacher啟動的時間和緩存加熱的程度。當然啦，緩存加熱的程度越好，使用的時間就會越長，但往往，我們并不希望過長的seacher啟動時間。這個autowarm 參數可以在solrconfig.xml文件中被設置。
詳細的配置可以參考solr的wiki。
Cache hit rate（緩存命中率）
我們可以通過solr的admin界面來查看緩存的狀態信息。提高solr緩存的大小往往是提高性能的捷徑。當你使用面搜索的時候，你或許可以注意一下filterCache,這個是由solr實現的緩存。
Explicit Warming of Sort Fields
如果你有許多域是基于排序的，那么你可以在"newSearcher"和"firstSearcher"event listeners中添加一些明顯需要預熱的查詢，這樣FieldCache 就會緩存這部分內容。
Optimization Considerations
優化索引，是我們經常會做的事情，比如，當我們建立好索引，然后這個索引不會再變更的情況，我們就會做一次優化了。
但，如果你的索引經常會改變，那么你就需要好好的考慮下面的因素的。
- 當越來越多的索引段被加進索引，查詢的性能就會降低， lucene對索引段的數量有一個上限的限制，當超過這個限制的時候，索引段可以自動合并成為一個。
- 在同樣沒有緩存的情況下，一個沒有經過優化的索引的性能會比經過優化的索引的性能少10%……
- 自動加熱的時間將會變長，因為它依賴于搜索。
- 優化將會對索引的分發產生影響。
- 在優化期間，文件的大小將會是索引的兩倍，不過最終將會回到它原來的大小，或者會更小一點。
優化，會將所有的索引段合并成為一個索引段，所以，優化這個操作其實可以幫助避免“too many files”這個問題，這個錯誤是由文件系統拋出的。
Updates and Commit Frequency Tradeoffs
如果從機太經常從主機更新的話，從機的性能是會受到影響的。為了避免，由于這個問題而引起的性能下降，我們還必須了解從機是怎樣執行更新的，這樣我們才能更準確去調節一些相關的參數（commit的頻率，spappullers,autowarming/autocount）,這樣，從機的更新才不會太頻繁。
- 執行commit操作會讓solr新生成一個snapshot。如果將postCommit參數設成true的話，optimization也會執行snapShot.
- slave上的Snappuller程序一般是在crontab上面執行的，它會去master詢問，有沒有新版的snapshot。一旦發現新的版本，slave就會把它下載下來，然后snapinstall.
- 每次當一個新的searcher被open的時候，會有一個緩存預熱的過程，預熱之后，新的索引才會交付使用。
這里討論三個有關的參數：
- number/frequency of snapshots ----snapshot的頻率。
- snappullers 是 在crontab中的，它當然可以每秒一次、每天一次、或者其他的時間間隔一次運行。它運行的時候，只會下載slave上沒有的，并且最新的版本。
- Cache autowarming 可以在solrconfig.xml文件中配置。
如果，你想要的效果是頻繁的更新slave上的索引，以便這樣看起來比較像“實時索引”。那么，你就需要讓snapshot盡可能頻繁的運行，然后也讓 snappuller頻繁的運行。這樣，我們或許可以每5分鐘更新一次，并且還能取得不錯的性能，當然啦，cach的命中率是很重要的，恩，緩存的加熱時間也將會影響到更新的頻繁度。
cache對性能是很重要的。一方面，新的緩存必須擁有足夠的緩存量，這樣接下來的的查詢才能夠從緩存中受益。另一方面，緩存的預熱將可能占用很長一段時間，尤其是，它其實是只使用一個線程，和一個cpu在工作。snapinstaller太頻繁的話，solr slave將會處于一個不太理想的狀態，可能它還在預熱一個新的緩存，然而一個更新的searcher被opern了。
怎么解決這樣的一個問題呢，我們可能會取消第一個seacher，然后去處理一個更新seacher，也即是第二個。然而有可能第二個seacher 還沒有被使用上的時候，第三個又過來了。看吧，一個惡性的循環，不是。當然也有可能，我們剛剛預熱好的時候就開始新一輪的緩存預熱，其實，這樣緩存的作用壓根就沒有能體現出來。出現這種情況的時候，降低snapshot的頻率才是硬道理。
Query Response Compression
在有些情況下，我們可以考慮將solr xml response 壓縮后才輸出。如果response非常大，就會觸及NIc i/o限制。
當然壓縮這個操作將會增加cpu的負擔，其實，solr一個典型的依賴于cpu處理速度的服務，增加這個壓縮的操作，將無疑會降低查詢性能。但是，壓縮后的數據將會是壓縮前的數據的6分之一的大小。然而solr的查詢性能也會有15%左右的消耗。
至于怎樣配置這個功能，要看你使用的什么服務器而定，可以查閱相關的文檔。
Embedded vs HTTP Post
使用embeded 來建立索引，將會比使用xml格式來建立索引快50%。
RAM Usage Considerations（內存方面的考慮）
OutOfMemoryErrors
如果你的solr實例沒有被指定足夠多的內存的話，java virtual machine也許會拋outof memoryError，這個并不對索引數據產生影響。但是這個時候，任何的 adds/deletes/commits操作都是不能夠成功的。
Memory allocated to the Java VM
最簡單的解決這個方法就是，當然前提是java virtual machine 還沒有使用掉你全部的內存，增加運行solr的java虛擬機的內存。
Factors affecting memory usage（影響內存使用量的因素）
我想，你或許也會考慮怎樣去減少solr的內存使用量。
其中的一個因素就是input document的大小。
當我們使用xml執行add操作的時候，就會有兩個限制。
- document中的field都是會被存進內存的，field有個屬性叫maxFieldLength，它或許能幫上忙。
- 每增加一個域，也是會增加內存的使用的。