一次搜索服务优化笔记

测试环境

CentOS release 5.5系统，内核版本：Linux version 2.6.18-194.el5

Intel(R) Xeon(R) CPU E5640 @ 2.67GHz 16CPU；64G内存；千兆网卡

300w用户数据，大概1G的索引文件。lucene 3.6.1

基于lucene实现的搜索服务，索引文件是文件类型的，Directory为MMapDirectory.

 

目的

只对搜索的rpc接口进行压力测试

 

条件

100个搜索任务（搜索参数随机组合）同时进行压力测试，发现tps大概是400/s左右，从编码上优化，将索引文件拆解为10个sub index，使用MultiReader，然后由10 sub IndexReader对应每个sub index，通过多线程完成每次搜索，结果发现搜索效率提升不大。

通过 sar -n / iostats 监控发现磁盘读写利用率为0%，也就说瓶颈不在磁盘io上。

同时cpu利用率/jvm垃圾回收都正常，搜索服务器的工作线程从1k提升到1.5k对tps有些许提升，效果不大，而且cpu load大概在7-10左右。

将压力测试请求任务提升到300、1000之后，请求响应的平均时间、最大时间逐渐增大至不可接受的时间。而磁盘io、cpu load基本没有变化，jvm gc频率增大。也就是说每次搜索需要大量的cpu运算，在资源足够的情况下，cpu运算和线程竞争的瓶颈是无法避免的。

根据网上提供的解决方案：

1.通过FieldFilterCache的方式来缓存某个字段的搜索结果，然后通过子搜索条件来从cache中查找数据，但实际中发现lucene是将FieldFilterCache和子搜索结果做交集，效率更差，而且FieldFilterCache的数据是放在WeakedHashMap中,数据如果被gc回收了，效率就更慢了。放弃此种方案

2.减少Collector返回的totalHit数据，lucene很实诚，每次搜索都会返回符合搜索条件的精准数据，这导致全索引扫描，而实际业务中只需要100条数据，不需要太精确的totalHit。故考虑自定义Collector实现，后来发现时间、精力、能力已经不允许在lucene3.6中自定义Collector实现了---项目要上线了。放弃此种方案

 

 

调整

根据实际业务情况调整：

用户的搜索条件基本固定，而且产品人员要求在翻页的情况下要保证数据的顺序是不变的，即从第二页到第N页然后在回退到第二页，第二页的数据不能因为索引的更新导致展现的数据不一致，考虑的解决方案：加缓存。因为搜索结果是按照时间排序，使用redis SortedSet来存储搜索结果。缓存架构如下：

用户级别缓存：搜索条件+用户个性设置的结果。数据是从 搜索条件缓存中计算出来的。而且这2级缓存过期时间不同，用户级缓存可以被用户的特定请求主动穿透，过期时间设置比较久，搜索级缓存时间比较短，是为了避免用户级缓存被穿透后，对造成请求风暴，压力过大。

300线程，1000个搜索条件随机请求，tps大概在4k-8k/s。压力线程增加到1k，tps依然在4k-8k/s。通过 sar命令监控网卡流量，大概在20m-30m之前浮动，未达到千兆网卡的实际极限传输速度( 125MB/s).在测试工程中，通过java方法级别的监控工具发现rpc调用的网络io没有write block，这也情况也证明网络并非瓶颈。

关于JVM参数，因为使用的是jdk6最新的版本，新加了2个参数： -XX:+UseCompressedOops，来减少64位机中新增对象句柄占用的空间。-XX:+UseNuma，根据Numa架构分配eden区空间，据Oracle官方文档介绍，能够提升gc并行回收的效率（32位机：30%提升，64位机：40%提升）。参考：http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html

 

总结

性能测试要关注测试环境的网络IO、磁盘IO、CPU利用率、内存利用率。如果这些硬件环境没有达到极限，就是代码存在瓶颈，在我开始做压力测试的时候，将搜索服务工作线程默认设置为5个，导致tps极低，后来经过分析发现工作线程数量限制导致的。。。而且做优化需要根据实际的业务情况来进行才能事半功倍，ps：cache真是web应用在高并发情况下保证响应的利器。

 

不足

没有通过java profile详细监控每个线程的响应时间(jprofile/yourKit)、竞争的原因

 

摘自互联网