indexed fields 的數量將會影響以下的一些性能：

• 索引時的時候的內存使用量
• 索引段的合并時間
• 優化時間
• 索引的大小

我們可以通過 將 omitNorms=“true” 來減少indexed fields數量增加所帶來的影響。

Retrieving the stored fields 確實是一種開銷。這個開銷，受每個文檔所存儲的字節影響很大。每個文檔的所占用的空間越大，文檔就顯的更稀疏，這樣從硬盤中讀取數據，就需要更多的i/o操作（通常，我們在存儲比較大的域的時候，就會考慮這樣的事情，比如存儲一篇文章的文檔。）

可以考慮將比較大的域放到solr外面來存儲。如果你覺得這樣做會有些別扭的話，可以考慮使用壓縮的域，但是這樣會加重cpu在存儲和讀取域的時候的負擔。不過這樣卻是可以較少i/0的負擔。

如果，你并不是總是使用 stored fields 的話，可以使用stored field的延遲加載，這樣可以節省很多的性能，尤其是使用comPRessed field 的時候。

這個是合并因子，這個參數大概決定了segment(索引段)的數量。

合并因子這個值告訴lucene，在什么時候，要將幾個segment合并成為一個segment, 合并因子就像是一個數字系統的基數一樣。

比如說，如果你將合并因子設成10，那么每往索引中添加1000個文檔的時候，就會創建一個新的索引段。當第10個大小為1000的索引段添加進來的時候，這十個索引段就會被合并成一個大小為10，000的索引段。當十個大小為10，000的索引段生成的時候，它們就會被合并成一個大小為100，000的索引段。如此類推下去。

這個值可以在 solrconfig.xml 中的 *mainIndex*中設置。（不用管indexDefaults中設置）

較高的合并因子

• 會提高索引速度
• 較低頻率的合并，會導致 更多的索引文件，這會降低索引的搜索效率

較低的合并因子

• 較少數量的索引文件，能加快索引的搜索速度。
• 較高頻率的合并，會降低索引的速度。

當一個新的 searcher 打開的時候，它緩存可以被預熱，或者說使用從舊的searcher的緩存的數據來“自動加熱”。autowarmCount是這樣的一個參數，它表示從舊緩存中拷貝到新緩存中的對象數量。autowarmCount這個參數將會影響“自動預熱”的時間。有些時候，我們需要一些折中的考慮，seacher啟動的時間和緩存加熱的程度。當然啦，緩存加熱的程度越好，使用的時間就會越長，但往往，我們并不希望過長的seacher啟動時間。這個autowarm 參數可以在solrconfig.xml文件中被設置。

詳細的配置可以參考solr的wiki。

我們可以通過solr的admin界面來查看緩存的狀態信息。提高solr緩存的大小往往是提高性能的捷徑。當你使用面搜索的時候，你或許可以注意一下filterCache,這個是由solr實現的緩存。

詳細的內容可以參考 solrCaching這篇wiki。

如果你有許多域是基于排序的，那么你可以在"newSearcher"和"firstSearcher"event listeners中添加一些明顯需要預熱的查詢，這樣FieldCache 就會緩存這部分內容。

優化索引，是我們經常會做的事情，比如，當我們建立好索引，然后這個索引不會再變更的情況，我們就會做一次優化了。

但，如果你的索引經常會改變，那么你就需要好好的考慮下面的因素的。

• 當越來越多的索引段被加進索引，查詢的性能就會降低， lucene對索引段的數量有一個上限的限制，當超過這個限制的時候，索引段可以自動合并成為一個。
• 在同樣沒有緩存的情況下，一個沒有經過優化的索引的性能會比經過優化的索引的性能少10%……
• 自動加熱的時間將會變長，因為它依賴于搜索。
• 優化將會對索引的分發產生影響。
• 在優化期間，文件的大小將會是索引的兩倍，不過最終將會回到它原來的大小，或者會更小一點。

優化，會將所有的索引段合并成為一個索引段，所以，優化這個操作其實可以幫助避免“too many files”這個問題，這個錯誤是由文件系統拋出的。

如果從機太經常從主機更新的話，從機的性能是會受到影響的。為了避免，由于這個問題而引起的性能下降，我們還必須了解從機是怎樣執行更新的，這樣我們才能更準確去調節一些相關的參數（commit的頻率，spappullers,autowarming/autocount）,這樣，從機的更新才不會太頻繁。

1. 執行commit操作會讓solr新生成一個snapshot。如果將postCommit參數設成true的話，optimization也會執行snapShot.
2. slave上的Snappuller程序一般是在crontab上面執行的，它會去master詢問，有沒有新版的snapshot。一旦發現新的版本，slave就會把它下載下來，然后snapinstall.
3. 每次當一個新的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的頻率才是硬道理。

在有些情況下，我們可以考慮將solr xml response 壓縮后才輸出。如果response非常大，就會觸及NIc i/o限制。

當然壓縮這個操作將會增加cpu的負擔，其實，solr一個典型的依賴于cpu處理速度的服務，增加這個壓縮的操作，將無疑會降低查詢性能。但是，壓縮后的數據將會是壓縮前的數據的6分之一 的大小。然而solr的查詢性能也會有15%左右的消耗。

至于怎樣配置這個功能，要看你使用的什么服務器而定，可以查閱相關的文檔。

使用embeded 來建立索引，將會比使用xml格式來建立索引快50%。

如果你的solr實例沒有被指定足夠多的內存的話，java virtual machine也許會拋outof memoryError，這個并不對索引數據產生影響。但是這個時候，任何的 adds/deletes/commits操作都是不能夠成功的。

最簡單的解決這個方法就是，當然前提是java virtual machine 還沒有使用掉你全部的內存，增加運行solr的java虛擬機的內存。

我想，你或許也會考慮怎樣去減少solr的內存使用量。

其中的一個因素就是input document的大小。

當我們使用xml執行add操作的時候，就會有兩個限制。

• document中的field都是會被存進內存的，field有個屬性叫maxFieldLength，它或許能幫上忙。
• 每增加一個域，也是會增加內存的使用的。