大致有下面几类特征应用
一类 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.测试****页面，模拟最复杂的查询方式，关注页面性能。
