最近，公司领导让我做下性能方面的竞品对比，作为一个性能测试小白的我，突然接到这样的任务，下意识发出大大的疑问。

　　整理好心情，内心想着“领导一定是为了考验我，才给我这个任务的”，开始了这一次性能测试之旅。

　　我学着开发同学在Github上寻找代码复制粘贴的姿势，去寻找时序数据库领域有没有类似于关系型数据库的benchmarksql的性能测试工具，且能够支持某数据库协议。很快就发现了comparison工具，但它没有提供二进制下载，这不是啥问题，作为学过几天编程的我，编译安装Go程序还是很擅长的，于是熟练的敲下go install，但是却......

　　我以为只有我这种编程小白才会出现编译失败，为啥流行产品的官方工具也会......

　　没关系，继续找，然后找到了基于comparison工具修改的tsbs工具，由timescaledb进行维护，简单查看了下代码结构和使用方法（我也就只能简单看看……），基本和comparison工具一致，感觉应该靠谱。

　　这一次工具的获取和使用都没有问题，于是准备开始”愉快“的测试过程。然后，然后就emo了。。。

　　TSBS让我Bad Shit(糟糕透顶)

　　tsbs工具的使用方式和缺点真让人抓狂，随着测试的进行，精神内耗极具增加~~~~这是为什么呢？因为在测试过程中出现了以下问题：

　　1. SQL查询返回结果为空时没有警告

　　进行某一次测试的时候，完成测试所花费的时间明显快于预期（因为那些SQL按理不应该执行那么快），且服务器硬件资源消耗也低于预期，作为测试人员，对于这种现象还是不能放过的。所以立即进行排查，这一排查就是半天，最后才发现是因为tsbs_generate_queries工具使用的scale和tsbs_generate_data的scale值不一样，导致生成的查询SQL中的条件与实际数据集不吻合，导致部分SQL不需要读取数据，所以执行非常快。

　　这里产生的易用性问题就有两个：

　　一、两个工具的参数需要保持一致，但在不熟悉的情况下可能会设置得不一致，导致如上述测试那样不充分、不公平的问题。

　　二、当SQL返回数据为空的时候，工具没有警告。通常，性能测试执行的SQL应该返回数据，测试工具也应该验证是否有返回数据。那么即便由于第一个问题导致参数设置不匹配，也会及时发现，就不需要浪费时间排查问题了。

　　2. 手动执行，且次数太多

　　领导要求对tsbs支持的SQL用例都需要进行测试。如下所示：　　

The use case matrix of choices is:use case: devops, query type: single-groupby-1-1-12use case: devops, query type: high-cpu-1use case: devops, query type: single-groupby-5-1-1use case: devops, query type: cpu-max-all-8use case: devops, query type: double-groupby-1use case: devops, query type: double-groupby-5use case: devops, query type: single-groupby-1-1-1......

　　共45个用例，分属于三个数据集。每个用例需要执行生成数据文件，写入数据，生成SQL语句，执行SQL语句四次命令行语句，每个用例执行三次。总计需要我手动执行45*4*3=540次命令行语句。就算不心疼回车键，命令执行的时候，我们需要等待命令执行完成也需要花费时间。（自动化...咚咚咚...自动化...咚咚咚）

　　3. 无法控制测试时长

　　用例测试执行的结束条件是将生成的SQL全部执行完成。但是对于测试执行人员来说，这里就有问题。比如，同样是10w条SQL，对于QPS能够到达1000/s的语句来说，只需执行100s，而对于QPS只有10/s的语句却需要10000s，这个执行时间根据不同SQL或数据库服务差别很大。

　　我们希望能够控制的测试总时长。

　　使用tsdb工具进行测试时，对于测试人员来说，需要首先进行“探索”，获得一个合理的SQL总数，从而有一个可接受的执行时间，否则可能等待特别久。并且，针对某数据库探索出的合理SQL集，拿去测试另外的数据库时，可能又需要等待很长时间。

　　4. SQL语句有限

　　tsbs的语句有限，仅有第2点所列的。如果有需求需要添加新的SQL语句，则需要在tsbs程序代码中添加代码，既麻烦又有难度。

　　5. 性能结果没有对应具体SQL语句

　　tsbs需要在选择场景（use case）和类型（type）生成SQL语句后才能看到具体的测试SQL语句。当测试完毕发现性能测试结果不理想时，我们也只能知道是哪个场景或类型不理想，但却不知道具体是哪条SQL不理想，这需要测试人员进行猜测或者挨个试，这对于性能测试后的性能分析来说，是非常麻烦且浪费时间的事情。

　　6. 不支持混合读写场景

　　其实对于性能测试来说，更符合实际的场景是同时有读请求和写请求的场景。所以，如果工具能够支持混合读写场景，对于来衡量一个数据库的性能是很重要的。

　　7. 工具太零散，参数设置易出错

　　不仅仅是工具太多太零散，且它们的参数需要保持一致才能得出合理的测试结果，但每个工具参数又比较多，稍有疏忽就容易导致参数设定不一样，有可能测试出不合理的结果却还不知情，以至于得出错误的结论。

　　8. 没有自动记录结果

　　tsbs需要测试人员自行手动记录每条命令的测试结果，特别麻烦还容易记错。

　　......不多说了，心累

　　这就样痛苦的执行命令，持续了半天，达到了精神内耗的极点了，忍无可忍之下，使出了小白的最大必杀技----大佬召唤术，大佬~大佬~

　　大佬看了下我的测试需求和问题，听着我的吐槽，插上键盘，开始了他的表演。

　　最终花了一个月，每晚熬到12点（愿意花一个月的时间，是因为后续的性能对比测试会做很多遍，所以决定花费一定时间来节省后续的测试时间）基于comparison工具进行了修改和优化，写出了我们自己的性能测试工具fcbench（这个燕国地图长度还行吧，各位秦始皇请看...）

　　FCBench让我First Cheerful(非常愉悦)

　　气氛都烘托到这里了，咱们赶紧趁热打铁列举一下fcbench与comparison工具相比较的优点。

　　1. 将多个tsdb命令整合

　　将tsbs各个命令，例如tsbs_generate_queries,tsbs_run_queries_influx等，整合成一个命令schedule，schedule的操作对象为一个testcase。每个testcase包含如下阶段：

　　a. 清理环境（可选）

　　fcbench支持连跑用例（也为了性能自动化对比做准备），所以可以在case的配置文件中指定是否进行清理环境。注：即使不清理环境也会进行重启数据库。清理环境可以排除不同测试场景或者多个版本独立测试的干扰。

　　b. 准备数据（可选）

　　这里的准备数据和tsbs的准备数据文件不同，fcbench是向目标数据库中写入一定量的数据，作为数据查询的目标对象。

　　c. 自动执行多个测试用例

　　d. 结果自动收集

　　2. 自动化用例执行

　　fcbench支持连跑用例，无需人工干预。通过一个agent命令在目标机器（服务端）运行，通过发送http请求的方式控制数据库的启动，删库，初始化，停止等操作。这样可以连跑用例，而不是像tsbs一样，一行一行的bash命令的执行。比如可以一晚上连跑测试，等着第二天看结果即可，需要做的就是准备如下所示的一个测试用例文件：

　　

　{"Group":"车载Series变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":1,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}{"Group":"车载Series变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":1000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}{"Group":"车载Series变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}{"Group":"车载Series变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":100000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}{"Group":"车载batchsize变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":10,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}{"Group":"车载batchsize变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":100,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}{"Group":"车载batchsize变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}{"Group":"车载batchsize变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":5000,"ScaleVar":10000,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}{"Group":"车载采样时间变化","MixMode":"write_only","UseCase":"vehicle","Workers":64,"BatchSize":1000,"ScaleVar":10000,"SamplingIn

　　3. 支持SQL模板

　　tsbs执行的SQL只有有限的几个，如果需要增加SQL语句进行测试，需要在代码层面进行添加。fcbench提供SQL模板的方式，可以编写模板来执行任意SQL。例如：

　　select aqi from city_air_quality where site_id = '{site_id}' order by time desc limit 1"

　　上方的'{site_id}'在执行的时候，会根据数据集中site_id列中值进行填充后进行测试，且与tsbs一样，每个请求中携带sql的site_id都不一样

　　4. 自动收集结果

　　fcbench对于每一个用例（对应测试用例文件中每一行）都会生成结果收集，并生成csv文件，方便后续进行处理和分析。其中包含语句失败次数，响应时间（平均值，p90，p95，p99），qps等。不需要测试人员等待测试完成手动记录。

　　5. 方便扩展

　　通过良好的架构设计，只需要为特定的数据库增加代码，无需修改已有代码，就可支持其他类型的数据库。

　　有了fcbench，终于可以愉快的进行性能测试，精神内耗也开始慢慢恢复了~~~

　　当然这仅仅是对比测试，得到测试结果，其实完整的性能测试还需要做很多事情，比如资源监控，瓶颈分析，参数调优等，作为小白，我的性能测试之路才刚刚开始。