在之前的文章中,我都提到过QPS计算的两种公式,今天特意来研究一下在固定线程模型下,两种统计公式误差问题。

QPS = 总请求量除以总时间,以下:
QPS = count(r)/T

QPS = 线程数除以平均响应时间
QPS = thread/rt

计算模型

如图所示,这是单个线程单个请求的耗时简易模型,分成三部分:请求前(对应before)、请求与响应(对应request and response)和请求后(对应after)。其中T代表三个部分的总时间,rt代表了请求与响应的时间。

请求计算模型

fds

误差来源

理论误差

这部分误差来源其实就是beforeafter两部分。不同于FunTester测试框架中的before()after()方法。这里代表的是每次请求之前和请求之后进行的各种处理。

请求前的时间消耗在性能测试中,经常会进行请求前的数据引入、参数处理和请求设置等等。举个例子:在请求之前要拼装URL,获取字符型数字型参数(可能是随机参数亦或从配置中获取),组装成请求对象HttpRequestBase等等。这些都需要时间,但是很短。耗时比较长的有可能是读取MySQL巨量的数据加锁的数据参数运算等。

在请求后的时间消耗,大多数都是请求结果的解析和响应,例如测试工具和框架的基本验证,用户自己编写的各类断言,解析数据赋值变量等等。其中工作中常遇到的使用正则表达式和其他脚本引擎(即使用SDK)进行响应解析会消耗比较长的时间。可以参考文章:JMeter 吞吐量误差分析中的例子。

利用微基准测试修正压测结果中,遇到一种参数签名导致消耗时间过长,导致测试结果误差偏大,必需要进行空转的基准测试修正压测结果。

实际误差

这类误差来源是我根据经验划分的,是一些通用的理论上影响不大,或者在实际工作中发现脱离理论之外的情况。就如上图请求计算模型中所示,这其实也是一种理想化模型。

下面是我总结的一些来源:

日志打印

这个日志打印包括了正常日志和测试中文件读写。

由于性能测试数据量比较大,如果不加以区分和过滤,直接将所有日志都输出到文件中,那么必然会导致整个测试用例执行过程中的较大误差。之前经常能够看到有粉丝提问如果处理JMeter的测试日志中的数据。这些文件往往不只是几百 M,而是以 G 为单位。试问,如果是串行日志输出,那么单单写入这些日志的时间消耗就必需进行数据的修正了。

在实际测试中,很多人并不会在意JMeter等工具的系统日志,因为实在太多了。而是会通过使用某个元器件(假设存在这个功能)或者工具的API进行个性化的日志输出。比如我之前写过的:用 Groovy 处理 JMeter 断言和日志中使用Groovy脚本引擎独立个性化处理日志和用 Groovy 记录 JMeter 请求和响应中根据响应结果分别记录异常的请求的功能。如果数据量比较小,消耗基本都在微秒级别,但是一旦发生以外情况,需要大量的数据记录时,又会回到日志记录相同的问题,影响测试结果。

数据实时处理

在部分的测试框架和测试工具中,测试中的数据是会实时展示的,包括常用的QPSrt95%total等指标,还会监控服务端的各项指标。包括将这些指标计算绘图等等操作,都是非常耗时的,而且消耗更多硬件资源,不利于测试准确性的提高。大部分工具卡死都是因为在GUI执行测试用例的时候,各种实时数据处理占用过多硬件资源导致的,实不可取。目前我一直采用数据的后处理,既在测试完成之后进行数据的统计和分析。


FunTester腾讯云年度作者Boss 直聘签约作者GDevOps 官方合作媒体,非著名测试开发 er。


↙↙↙阅读原文可查看相关链接,并与作者交流