响应式网站开发实例,网站建设优化服务资讯,建设一个网站需要注意哪些要求,建设银行河北分行官网招聘网站最近#xff0c;公司领导让我做下性能方面的竞品对比#xff0c;作为一个性能测试小白的我#xff0c;突然接到这样的任务#xff0c;下意识发出大大的疑问。
整理好心情#xff0c;内心想着“领导一定是为了考验我#xff0c;才给我这个任务的”#xff0c;开始了这一…最近公司领导让我做下性能方面的竞品对比作为一个性能测试小白的我突然接到这样的任务下意识发出大大的疑问。
整理好心情内心想着“领导一定是为了考验我才给我这个任务的”开始了这一次性能测试之旅。
我学着开发同学在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*3540次命令行语句。就算不心疼回车键命令执行的时候我们需要等待命令执行完成也需要花费时间。自动化...咚咚咚...自动化...咚咚咚 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等整合成一个命令scheduleschedule的操作对象为一个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文件方便后续进行处理和分析。其中包含语句失败次数响应时间平均值p90p95p99qps等。不需要测试人员等待测试完成手动记录。
5. 方便扩展
通过良好的架构设计只需要为特定的数据库增加代码无需修改已有代码就可支持其他类型的数据库。
有了fcbench终于可以愉快的进行性能测试精神内耗也开始慢慢恢复了~~~
当然这仅仅是对比测试得到测试结果其实完整的性能测试还需要做很多事情比如资源监控瓶颈分析参数调优等作为小白我的性能测试之路才刚刚开始。
感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走
这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
