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