标签：sphinx epoll
原创，转载请务必保留作者及本文出处(连接形式)。
2年前工作中的内容，已成过眼烟云，分享一下，欢迎交流。
1.之前的优化效果
之前对sphinx线程处理，网络IO做了很多优化（netty、epoll、libevent），索引部分也做了优化，从目前测试结果来看，性能提升已经到了瓶颈，尤其是全部搜索，线程调度，网络 IO优化对于这种查询方式帮助很小。对于单节点性能提升，还得从索引本身查询算法入手优化。sphinx的属性过滤对性能本身有很大影响，但是优化空间不 是很大，读取的属性是离散的，不像索引是可以连续读取的，这种操作受限于物理硬件性能。目前可以优化的主要还是索引查询部分，这两天通过写一些demo， 模拟索引和查询算法对搜索流程定量分析。
2.索引分析
目前只考虑了两种算法和索引的性能分析，第一种是sphinx现在的查询方式和索引结构，第二种是某兄之前说的某搜索公司的位图索引。
现在的查询方式性能统计：
1.1000万数据，通过增量压缩的方式（这里面为了方便对比，增量都是1个字节），压缩后读取索引时间是2597us。
在读取缓存区大于8K以后，基本 上变化不大。加载到内存后，循环一个一个读取字节，不做解压缩，需要时间65645us，
循环了1000万次；如果边读取边解压，需要142438us, 相当于77ms的时间用在了解压操作上。
2.1000万数据，不做压缩，以int的方式直接存储（目前sphinx用的long,对于我们来说，只保存内存属性偏移地址，
int就足够了），存储 文件是原来的4倍，读取时间10470us,多了8ms的读取时间，循环读取int ，无需解压操作，
用了86493us。
3.两个1000万数据列表做and操作，都采用不压缩的形式存储，整个操作时间为482461us,平均下来300ms的时间
用在了比较操作上了
基于位图运算：
1. 2000万位的两个位图列表，对位图执行and 操作，用时1855us，基本上不耗什么时间。对位图结果，遍历查询结果，
这个时间受结果集的大小限制。结果为空的时候，时间最短，不到2ms,如果结果很多，需要27ms。
2.位图压缩操作使用的是zlib，这个比较耗时，2000万的位图压缩需要300-600ms, 压缩的大小和位图相关，即时空位
图，压缩后也有2K，最大不会超过原始大小。
3.位图解压操作，耗时需要10-30ms，即时空位图，最小耗时也会在10ms。
读取文件 逐个读取 解压缩 And操作 提取结果
sphinx压缩索引 <3ms <65ms <77ms 未测试 无需此项操作
sphinx不压缩索引 <12ms <86ms 无需解压缩 300ms 无需此项操作
位图 <1ms 无需此项操作 10~30ms <2ms <27ms
对比结果：
sphinx 查询方式 查询时间在1ms~500ms
位图查询方式查询时间在30ms~90ms
位图and 操作快，是因为采用64位与运算，相当于一次对64个数据比较，在倒排列表很大的情况下，性能优势就很突出了，如果倒排列表很小，大部分操作都是无用功。
新的测试结果
使用位图的数据直接存储并不合适，只有倒排列表超过两百万的时候，位图存储有优势，解压缩时间优于存储未压缩倒排
列表时间。在实际中，2000万数据中一个倒排列表超过200万的数据是少数。所以还是使用未压缩的int存储比较合适，在
读的时候再设置位图,用位图做后续与或运算，这样可以既可以兼容之前的索引结构， 又可以提高倒排列表合并的性能。
3.结论
总体上来看，sphinx 查询方式性能波动很大，在大数据量的情况下，下降很明显，位图相比之下性能波动更加平滑。sphinx目前采用的这种压缩方式，实际上意义不大，反而增加了cpu开销。对于普通搜索（查询结果，返回结果数），这种查询方式使用位图优势更加明显一些。对于不需要结果数，只返回前n条结果的这种查询方式，sphinx的查询可能会快一些，位图解压缩有一个最低消耗时间。
sphinx搜索引擎优化及测试
标签：sphinx epoll
原文地址：http://blog.csdn.net/ddl007/article/details/42646179
