心血来潮，写一篇小文跟大家来探讨一下我们引擎和算法的"性能基线"建立方式的话题。
   
    想法来敲门
   
    昨天下午和LX讨论基线的时候，LX提到他以前接触到的"性能基线"是：固定一组输入，然后测试系统在不同版本时候的性能表现。但是我们的性能基线却不具备这个特征，query经常要变化……
   
    这次谈话让我想起了以前在学校上IR（InformationRetrieval）的时候，有一个专题叫做IR的评价，其实是讲的IR系统的测试（记得还有人说过算法的评测比写算法更有难度）。之所以有这么一个专题是因为"IR的评价收到很多因素的影响，很难精确描述。由于评价环境的影响，某些性能数据仅在系统处于某个特定评价环境时才能得到。这样，由于测试环境不一致，没有公认的具有权威性的标准，会导致众说纷纭的局面"（原文摘录）。为了解决这样一个问题，人们搞出了"基准测试集"这么一个东西。
   
    那么什么是"基准测试集"呢？
   
    基准测试集有三部分构成：DocumentSet、QuerySet、RelevantJudgement.在比较多个IR系统孰优孰劣的时候，要做的是：使用统一的DecumentSet建立索引，然后使用统一的QuerySet去进行查询，后使用统一的judgement进行评判到底哪个IR系统更。
   
    国外有个专门的组织是干这个事情的，他叫TREC（TextRetrievalConference）。这个会议一直在致力于这样一个基准测试集的维护。当然它维护的是一个英文的文档集，并且是通用的，不适用于中文。但是他的方法和思想我们是可以借鉴的。
   
    我们可以这么做！
   
    个人认为，对于我们这边IR系统的性能测试，可以考虑这么构造我们的测试集：
   
    1、DocumentSet固定一定数量集的offer或者日志等信息；
   
    2、QuerySet这个是关键问题，会很大程度影响到终结果。我认为可以从下面两个角度来考虑构造这个QuerySet:
   
    ● 黑盒的用户角度从使用的角度来考虑可能会影响到性能的地方，比如：输入的查询词数量、返回结果结果的数据量等等。这种方式比较方便，便于实施。但是对于一些有可能会影响系统性能的特定逻辑考虑不到，比如：一些算法里对于没有结果的Query要做重写，重写的方式可能又有很多等，这种照顾不到。
   
    ● 白盒的工程师角度首先分析线上系统响应时间的log，把响应时间按照长短分成几个大类。比如20ms以上的，10-20ms的等等。然后使用profile工具去分析这些Query的响应时间不一致的根本原因在什么地方。通过这一系列的rootcauseanalysis的分析能够得到影响性能的几个关键因素。剩下的事情是构造一些列的Query去诱发这些因素的发生。这些Query是我们要的QuerySet.
   
    3、RelevantJudgement是响应时间或者QPS.
   
    建立好这种"基准测试集"以后，我想我们的性能可以尝试这么来做：
   
    ● typeⅠ测试（性能测试）对于我们构造好的有限个数的QuerySet，每个Query去做10次查询，取平均值作为该Query的响应时间。这样，如果QuerySet有5种类型的50个Query，那么有50个结果，代表了在这5种情况下系统的一个性能情况。把这个结果作为性能测试的结果，让大家都看到系统的性能在各种不同情况下的一个表现和变化。
   
    ● typeⅡ测试（稳定性测试）为了确保系统能够在线上无故障的运行，我们再做一组稳定性的测试。这种稳定性的测试必须是使用线上Query、多线程的、长时间的、但不需要是"没有思考时间的全压力下"的那种。之所以这样做也是为了真实的模拟线上情况，因为线上运行的时候系统面对的是这种多线程、时间长度不足24小时（每天要重新build索引，然后重启）、qps也是有100的这么一种压力。
   
    ProsandCons?
   
    我们采用这样一种方法的好处有：
   
    ● 让我们对于IR系统的性能表现和软肋有了更加深刻的认识这点我想无需解释，构造Queryset和执行测试的过程能够淋漓尽致的体现这一点。
   
    ● 彻底解决机器资源的争用问题按照上面的方法来做typeⅠ的测试，很快能完成，很快能够出结果。机器资源很好协调。对于typeⅡ的测试，可以在在一台机器上同时运行多个，因为我们的重点是系统长时间运行的可用性，并发数可以是8，但是qps能在一两百好了，这样来执行测试，即便是有四五个项目在做这种typeⅡ的测试也不会给系统带资源带来多么大的消耗。多条产品线有一套性能测试环境能满足需求。
   
    ● 可以提升后台算法和引擎性能测试的专业化程度我们常说性能测试的初级阶段是施压工具和性能指标收集工具的使用；进阶阶段是系统指标的分析和问题定位；中高阶段是结合应用的特性，综合考虑系统和应用的监控指标，来综合制定测试方案和分析定位问题了。这样做未尝不是一个好的方向。
   
    这样做的难处是：我们需要再次拥抱变化。不过，我们是aliren，相信如果大家在权衡利弊后只要相信一件事情是有价值的，那么剩下的是开搞啦~.
   
    写到后想起一句话，把这句话作为结语吧--"工程师的存在价值是：要么把枯燥单调的事情变得自动化起来，要么是把他们变得的有趣和刺激。"