weblucene 更新备忘--利用IndexReaderPool/IndexSearcherPool 改善search 的性能

来源:百度文库 编辑:神马文学网 时间:2024/04/28 21:02:34
利用IndexReaderPool/IndexSearcherPool 改善search 的性能
影响到search 性能的可能因素: CPU 开销: search 核心模块lucene的算法;
对原始结果进行二次处理的算法:如再排序处理、转换查询结果;
IO 开销:
lucene 在执行每个查询时都要先获得segments 文件中存储的索引信息(包括segment段数量、每个segment 文件的位置、索引中的记录总量、索引中的field 信息等等),一般是在读取segments 文件之前先生成一个commit.lock 文件,这样可以阻止其他的程序对其进行访问(即以排他方式读取segments 文件中的信息),在成功获取了索引信息后程序会自动删除commit.lock 文件。
在索引文件比较小、field 项比较少(如索引文件在500MB以下)的情况下获取索引信息的过程会比较快,一般在10ms 之内;但随着索引文件的增大,获取索引信息的过程就会拉长,当索引文件超过1000MB 的时候,这个过程一般会被拉长到10ms以上;索引文件在10000MB的时候这个过程会被拉长到40ms甚至更长。粗略统计,当索引文件超过1000MB的时候,获取索引信息的过程将占据整个查询过程的10%~15%。
另外,由于获取索引信息的过程是以排他方式进行的,所以在多个请求并发的情况下会发生等待的现象;在并发请求过多的时候甚至会出现commit.lock 长时间没有被删除的特殊情况,这时后续的查询请求将无法被正常处理、整个search 服务将被阻塞。
如果索引文件的更新频率比较低,那么就没有必要在处理每个查询的时候都获取一遍索引的信息。把索引信息缓存起来,供后续的查询使用,就可以大大提高后续查询的处理效率。具体的实现方式是设计IndexReaderPool 或IndexSearchPool 来保持索引信心直至索引被更新。