Solr的性能在solr4版本之后的得到了極大的提升，在使用過程中，盡量使用新的版本，在實踐中總結的一些性能優化參考，不同的業務場景需求，優化的方式會不一樣。
在設計field schema的時，需要關注indexed、stored、omitNorms這幾個屬性的值；indexed對索引的內存使用，segment的合並，索引的optimize，以及索引的大小都有影響，所以對於不需要索引的字段，indexed設置成false；stored屬性更多的影響存儲的IO，可以考慮綜合壓縮對IO和cpu之間消耗的平衡，也可以把非索引的字段放到其他數據庫中存儲。
omitNorms在建立索引時會存儲相關的影響boost打分的長度因子，因此對於不需要打分排序考慮的，omitNorm設置成true。
索引merge的頻率(mergeFactor)，其實就是optimize，對索引和搜索都有影響，merge是把所有的段合並成一個，將需要刪除或是被替換的索引標記為deleted，然后再創建新的文檔替換掉需要被替換的，有點像整理磁盤碎片的動作，會創建一個全新的索引結構便於提高搜索的效率，mergeFactor設大索引效率高，搜索效率低，同時mergeFactor越大消耗的內存越多，所以需要綜合考慮不同的場景的需求以及硬件設備環境來設定mergeFactor參數。
MaxMergeDocs、RAMBufferSizeMB 這兩個參數控制內存往硬盤刷新的頻率，兩者滿足一個條件時，就生成一個新的segment文件，一般是按照內存的消耗來進行刷新。
索引的存儲，一般是普通的SAS或者SATA盤，做raid1+0即可，對於IO要求比較高的場景中，可以使用SSD，FusionIO等設備。不同的索引最好分布在不同的目錄分區，減輕IO的壓力。
索引的壓縮(useCompoundFile)，通過合並到一個文件，減少文件的數量，減少文件句柄的使用，但是會降低索引的性能，消耗更多的時間，建議關閉復合文件。
實時索引NRT，Solr中的IndexReader基於當前目錄下的文件的索引的snapshot，對於實時的索引，如果要使得Reader搜索的到的話，必須重新基於文件索引當前snapshot進行重建，性能方面會不高，所以Solr3.6提供了NRT的softCommit方案，之前版本的方案基本上是內存和目錄的索引合並的方式。
索引的Directory有基於內存RAMDirectory，有基於硬盤文件的MMapDirectory、NIOFSDirectory；NIOFSDirectory利用nio讀取文件，比SimpleFSDirectory並發性能要高。MMapDirectory不是利用io來操作文件，而是利用內存映射。
多core，可以在一個Solr 實例上建立多個core，把索引分散在不同的core上，這樣避免所有的索引都在一個core中，顯得很臃腫；同時可以基於多core的swap，可以用於索引全量重建，而減少對搜索的影響，但是swap時會消耗cpu和內存。
在搜索方面，Solr包括這幾種cache，FilterCache、QueryResultCache、DocumentCache、FieldValueCache以及FieldCache。
Filtercache<Query,DocSets>應用在查詢fq，facet等場合，對於這兩個場景的使用，調優是很有必要的。
QueryResultCache<QueryResultKey,DocSets>需要關注命中率，和Query的start、rows以及queryResultWindowSize關系比較大，同時命中一個queryResultCache，需要滿足query、filterquery 、sortFiled一致才行；對於Query重合度較低的查詢，不建議開啟這個cache。
DocumentCache<doc_id,Document>，如果使用documentCache，就盡可能開大些，至少要大過<max_results> * <max_concurrent_queries>，否則因為cache的淘汰，一次請求期間還需要重新獲取document一次。也要注意document中存儲的字段的多少，避免大量的內存消耗。還有對於實時更新索引Searcher的場景，因docid在新的索引中是變化的，也不建議開啟DocumentCache。
FieldvalueCache，緩存在facet組件使用情況下對multiValued=true的域相關計數進行Cache，一般那些多值域采用facet查詢一定要開啟該Cache。
FieldCache是lucene中的cache，是IndexReader引用的，隨着IndexReader的關閉而釋放，
對於頻繁進行索引操作而實時更新搜索Searcher的場景，因Cache是依附於Searcher上的,不建議開啟Cache。
Cache的warm預熱，對於搜索來講，需要綜合兼顧考慮新的Seacher生效時間和搜索的性能。
當然Solr還在http層面提供了cache(httpCaching)，cache整個結果頁，這個用在索引很少更新的場景，cache完全脫離了solr層面。
隨着數據量和並發操作的增加，為了提供性能，需要對索引操作和搜索操作進行分離，solr4之前主要是master-slave方式，solr4之后采用分布式solrcloud。master節點進行寫操作，而slave節點進行讀操作，在solr1.1版本中是基於ssh/rsync的復制(Snapshot,Snappuller )，而solr1.4開始是基於http replication的pull復制機制，solr4即solrcloud的主從復制是基於push的replication機制。
在創建大量索引使用SolrInputDocument/Document的過程中，最好復用document和field對象，減少GC帶來的性能負擔。
writer單例化，多線程並發操作writer，以及索引操作和重新打開索引的性能在solr4中得到了極大的提高。