性能压测本身是一件非常有意义的事情，也是非常复杂的工作。对搜索引擎压测，不仅是数据集构建、查询集构建、 标准参照集构建等麻烦，而且只需一轮测试周期常，测试结果与语言本身有关联，更与集合其他数据有潜在关联，因为排序是 整体的，互关联的。
测试的具体执行环境、执行用例、参数配置和清除、querylog 解析、注意事项等，请咨询****同学。
一类 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等效的。建议，加压的时候，不仅仅关注:load\cpu\io，更要关注query响应时间。 任何一方面达到峰值或接近峰值，就应该停止加压，以当时的pqs为准。
没有统一的、唯一的性能指标，下面值给出通常情况下的性能指标参考，作为性能优化或者压测时的期望值。 以主站的baseTime=1000ms为例，按照2-8原理，
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中提取的。
平均hits=maxDoc*0.001,总文档数的千分之一平均命中 等于0hits=0 比例不超出5%，查询无命中结果控制在2%以内，否则需要执行输入提示或者查询条件的放宽。 这里面没有很好的参考，看具体情况吧。千分之一命中、98%有结果，单纯从数字看还是不错的。但是不代表 topN结果质量。 这一块性能是从querylog中提取出来。 hits 跟响应时间有什么关系吗 没有什么关系。相同hits的 响应时间不一定相等，但是当hits 非常大的时候 响应时间肯定增大
对于高频词的长链、最复杂的查询串(多个区间+facet或者多个facet或者多个区间或者多个OR等) 需要通过测试获取长链时间、极端查询串时间，这样就可以明了超时比例和超时可能的情况。 这里注意：单纯的针对性测试，不一定会暴露瓶颈，而混合其他查询一起的时候，问题就凸现了。索引，这部分 需要混合测试，也需要单独测试。然后考虑降低查询复杂度、优化cache、优化引擎数据结构了。
针对数据量有些大的应用，应该掌握全量一次消耗的时间和时间消耗点。
针对索引在线服务场景下，在线一次增量的数据量。从而确定增量间隔时间。时间太短，可能不停的增量，导致 数据一致延后。如果时间太长，导致新数据出来也延迟。另外，时间太短，增量过大，也可能出现OOM。
在分析了上面性能之后，才进入pqs测试，这样测出的数据更丰富，维度更多。
对于大数据构建的索引，离线分析索引结构，查找高频词、无效词、长尾词，反过来优化schema结构。
以下模板来自***同学提供，测试应用是相亲项目，相关开发同学:*****
非常感谢大家细致的建议！我做了如下计划，请确认下目标、场景、数据是否符合需求。
1.与老版对比，重点关注新版的[查询]性能。
跟***确认了，新版与老版的索引结构、查询逻辑都不一样，但是查询的主要用到的查询字段是一样的，可以通过对比，看新版性能如何。
2.老版页面超时
模拟复杂请求的页面查询，关注平均响应情况，统计超时比例，对于响应时间较长的请求，看是否可以优化
1.***搜索 - -P0
场景1: 关键词+facet+区间搜索 场景2: 关键词 场景3: 关键词+facet 建议：如果本次项目不是很关注facet性能，场景2、3是否可以不用测试。
2.页面压测 - -P1
分销页面展示：带上所有页面查询条件
3.测试场景参考
测试场景list：
场景1: 新*搜，关键词
场景2: 新*搜，关键词+facet
场景3: 新*搜，关键词+facet+区间搜索（正常区间）
场景4: 新*搜，关键词+facet+区间搜索（大区间0-999999）
场景5: 老*搜，关键词+facet+区间搜索（正常区间）查询
场景6：新*搜，***页面展示：带上所有页面查询条件
场景设计说明：场景1与2用于测试facet性能，3与4用于测试极限情况是否会超时，3与5用于测试新老**搜的对比，6用于测试线 上超时问题
查询请求准备15w条，新老查询请求从线上拉数据后，进行解析拼装，需要项目同学进行支持。
1.老版数据可以直接从线上拉，10w数据量，尽量减少查cache的情况 2.新版数据，需要对线上数据进行解析，重新拼装，10w数据量
注意：需要准备不同场景的数据，并进行解析，需要****的支持。
1.优先执行关键词+facet+区间搜索的性能测试，对比新老版本的性能情况，进行性能分析及调优。
2.测试****页面，模拟最复杂的查询方式，关注页面性能。
项目上线时间****，***性能测试项目计划在****号左右完成。由于准备数据及调试脚本需要1个工作日，执行测试并进行分析调优需4个工 作日。手头上还有一个项目在并行，因此相预计如此。
