SolrQuery性能压测参考-阿里云开发者社区

开发者社区> 阿里中间件> 正文

SolrQuery性能压测参考

简介: 性能压测本身是一件非常有意义的事情,也是非常复杂的工作。对搜索引擎压测,不仅是数据集构建、查询集构建、 标准参照集构建等麻烦,而且只需一轮测试周期常,测试结果与语言本身有关联,更与集合其他数据有潜在关联,因为排序是 整体的,互关联的。 测试的具体执行环境、执行用例、参数配置和清除、quer


大致有下面几类特征应用

一类 key-value,数据库join搬到倒排中而已, 代表应用 很大部分应用场景 一类 区间查询为主 代表应用 **** 一类 纯文本查,不存储,典型只查索引返回DB的索引id信息,代表应用 **** 一类 各种查询涵盖,facet、区间、group较多 典型代表 *** 如果应用场景相类似,已在线应用的性能或者历史压测数据具有一定的参考价值。 如果应用场景不类似,特别是有某个极端需求或者极端场景特征的话,通常需要具体测试和针对性优化。

搜索压测

性能压测需要关注:数据量、索引结构、查询特征、cache参数、硬盘配置,然后针对具体应用做具体压测。 基于的覆盖测试、功能测试、场景模拟是必须的,并且场景对性能的影响非常大,场景模拟的越真实,性能测试结果 就更有参考价值。 压测方式:

(1)线上分流,

将线上一部分请求引流到测试系统中。具体实现 可以是完整的一列作为测试对象,测试对象直接影响线上返回信息。 可以是线上系统之后,流量copy到测试系统中,测试系统不做信息返回,只是压测性能。 也可以是线上系统部分流量引流到测试系统,并且测试系统执行信息返回。

(2)线下模拟,

线下模拟对初始系统性能评估非常有帮助。线下模拟主要是模拟线上索引数据、查询数据、配置信息等,进行快速性能分析。 线下模拟更多信息,请参考下面性能指标信息。

注意实现

(1)覆盖用例。在搜索中覆盖用例越多越好,越不一样越好,例如关键词查询,高频、低频、普通用词都有,并且量尽量多。 如果覆盖的范围非常少,或者不同类型查询比例分配不合理,测出的性能也完全不一样。例如,实际场景有区间查询、 关键词查询、facet、group,而测试用例中各类型查询比例设置不合理,那么出来的结果完全不一样。 (2)索引结构。压测的索引结构应该就是线上索引结构,并且最好是数据规模比较大,数据越真实越好,人造数据或者少量 数据很难发现问题。 (3)查询特征:性能压测一般压关键查询特征。例如区间查询为主,那么性能测试中更突出区间查询的用例覆盖范围和 用例数量。 (4)cache 参数 有些应用中是配置了cache参数,也应该需要cache参数,此时需要针对不同参数值做一轮测试。 搜索的性能最终的飞跃完全依赖cache,尤其是io瓶颈很难突破的时候,cache就是主导了。 (5)jvm参数: 搜索是内存和io密集性计算,内存大往往性能较好,同时fgc因参数配置不合理,也对性能影响很大。 (6)何时停止加压 除了正常的load io cpu达到一个阈值时候,就停止加压。对应搜索,其他还有另外一个重要指标。 当出现较多的query超时,或者query时间超出预计值的时候,就不应该加压。尽管此时可能 load不是很高、cpu、io等值都没有达到峰值,但是,query的响应时间超时预期了。因为超预期的响应,意味者 查询失败,某种程度和exception等效的。建议,加压的时候,不仅仅关注:loadcpuio,更要关注query响应时间。 任何一方面达到峰值或接近峰值,就应该停止加压,以当时的pqs为准。

基本性能指标

没有统一的、唯一的性能指标,下面值给出通常情况下的性能指标参考,作为性能优化或者压测时的期望值。 以主站的baseTime=1000ms为例,按照2-8原理,

指标1----平均响应时间

80%的请求不能超过baseTime=1000ms,20%的请求控制在1.5*baseTime=1500ms 平均响应时间控制在 1000ms以内。 进一步细化: A类:0-50ms 80% |50 -100ms 10%|100-200ms 3% |200ms-500ms 3% |500-1000ms 3% | 1000ms-X 1% B类:0-100ms 80%|100-200ms 15%|200-500ms 2% |500-1000ms 2%| 1000ms - 1% C类:0-200ms 80%|200-500ms 15%|500-1000ms 3% |1000-1500ms 1% |1500- 1% 也即A类型 100ms内,B类型200ms内,C类型500ms内。 这一块性能也是从querylog中提取的。

指标2----命中率

平均hits=maxDoc*0.001,总文档数的千分之一平均命中 等于0hits=0 比例不超出5%,查询无命中结果控制在2%以内,否则需要执行输入提示或者查询条件的放宽。 这里面没有很好的参考,看具体情况吧。千分之一命中、98%有结果,单纯从数字看还是不错的。但是不代表 topN结果质量。 这一块性能是从querylog中提取出来。 hits 跟响应时间有什么关系吗 没有什么关系。相同hits的 响应时间不一定相等,但是当hits 非常大的时候 响应时间肯定增大

指标3----长链、极端查询

对于高频词的长链、最复杂的查询串(多个区间+facet或者多个facet或者多个区间或者多个OR等) 需要通过测试获取长链时间、极端查询串时间,这样就可以明了超时比例和超时可能的情况。 这里注意:单纯的针对性测试,不一定会暴露瓶颈,而混合其他查询一起的时候,问题就凸现了。索引,这部分 需要混合测试,也需要单独测试。然后考虑降低查询复杂度、优化cache、优化引擎数据结构了。

指标4----全量dump时间

针对数据量有些大的应用,应该掌握全量一次消耗的时间和时间消耗点。

指标5----增量吞吐量

针对索引在线服务场景下,在线一次增量的数据量。从而确定增量间隔时间。时间太短,可能不停的增量,导致 数据一致延后。如果时间太长,导致新数据出来也延迟。另外,时间太短,增量过大,也可能出现OOM。

指标6----qps情况

在分析了上面性能之后,才进入pqs测试,这样测出的数据更丰富,维度更多。

指标7----单纯索引分析

对于大数据构建的索引,离线分析索引结构,查找高频词、无效词、长尾词,反过来优化schema结构。

性能压测方案模板

以下模板来自***同学提供,测试应用是相亲项目,相关开发同学:***** 非常感谢大家细致的建议!我做了如下计划,请确认下目标、场景、数据是否符合需求。

测试目标

1.与老版对比,重点关注新版的[查询]性能。

跟***确认了,新版与老版的索引结构、查询逻辑都不一样,但是查询的主要用到的查询字段是一样的,可以通过对比,看新版性能如何。

2.老版页面超时

模拟复杂请求的页面查询,关注平均响应情况,统计超时比例,对于响应时间较长的请求,看是否可以优化

测试场景

1.***搜索 - -P0

场景1: 关键词+facet+区间搜索 场景2: 关键词 场景3: 关键词+facet 建议:如果本次项目不是很关注facet性能,场景2、3是否可以不用测试。

2.页面压测 - -P1

分销页面展示:带上所有页面查询条件

3.测试场景参考

测试场景list: <br> 场景1: 新*搜,关键词 <br> 场景2: 新*搜,关键词+facet <br> 场景3: 新*搜,关键词+facet+区间搜索(正常区间)<br> 场景4: 新*搜,关键词+facet+区间搜索(大区间0-999999) <br> 场景5: 老*搜,关键词+facet+区间搜索(正常区间)查询 <br> 场景6:新*搜,***页面展示:带上所有页面查询条件 <br> 场景设计说明:场景1与2用于测试facet性能,3与4用于测试极限情况是否会超时,3与5用于测试新老**搜的对比,6用于测试线 上超时问题 <br> 查询请求准备15w条,新老查询请求从线上拉数据后,进行解析拼装,需要项目同学进行支持。

测试数据

1.老版数据可以直接从线上拉,10w数据量,尽量减少查cache的情况
2.新版数据,需要对线上数据进行解析,重新拼装,10w数据量

注意:需要准备不同场景的数据,并进行解析,需要****的支持。

性能策略

1.优先执行关键词+facet+区间搜索的性能测试,对比新老版本的性能情况,进行性能分析及调优。

2.测试****页面,模拟最复杂的查询方式,关注页面性能。

时间计划

项目上线时间****,***性能测试项目计划在****号左右完成。由于准备数据及调试脚本需要1个工作日,执行测试并进行分析调优需4个工 作日。手头上还有一个项目在并行,因此相预计如此。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里中间件
使用钉钉扫一扫加入圈子
+ 订阅

为企业提供高效、稳定、易扩展的中间件产品

官方博客
链接