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中得到了极大的提高。
