一次搜索服务优化笔记

测试环境

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

Intel(R) Xeon(R) CPU E5640 @ 2.67GHz 16CPU64G内存;千兆网卡

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

基于lucene实现的搜索服务,索引文件是文件类型的,DirectoryMMapDirectory.

 

目的

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

 

条件

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

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

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

将压力测试请求任务提升到3001000之后,请求响应的平均时间、最大时间逐渐增大至不可接受的时间。而磁盘iocpu 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。压力线程增加到1ktps依然在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、磁盘IOCPU利用率、内存利用率。如果这些硬件环境没有达到极限,就是代码存在瓶颈,在我开始做压力测试的时候,将搜索服务工作线程默认设置为5个,导致tps极低,后来经过分析发现工作线程数量限制导致的。。。而且做优化需要根据实际的业务情况来进行才能事半功倍,pscache真是web应用在高并发情况下保证响应的利器。

 

不足

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

 

摘自互联网

你可能感兴趣的:(测试,压测,一次搜索服务优化笔记)