最近,公司领导让我做下性能方面的竞品对比,作为一个性能测试小白的我,突然接到这样的任务,下意识发出大大的疑问。
整理好心情,内心想着“领导一定是为了考验我,才给我这个任务的”,开始了这一次性能测试之旅。
我学着开发同学在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-12
use case: devops, query type: high-cpu-1
use case: devops, query type: single-groupby-5-1-1
use case: devops, query type: cpu-max-all-8
use case: devops, query type: double-groupby-1
use case: devops, query type: double-groupby-5
use 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,"SamplingInterval":"1s","TimeLimit":"5m","UseGzip":1,"QueryPercent":0,"PrePareData":"","NeedPrePare":false,"Clean":true,"SqlTemplate":null}
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,终于可以愉快的进行性能测试,精神内耗也开始慢慢恢复了~~~
当然这仅仅是对比测试,得到测试结果,其实完整的性能测试还需要做很多事情,比如资源监控,瓶颈分析,参数调优等,作为小白,我的性能测试之路才刚刚开始。
感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取