• 性能测试误差对比研究(四)


    之前写了一些在压测脚本中统计QPS可能造成误差的几种情况,今天补个坑,把剩余的几种都测试一下。

    • 前情回顾

    脚本采用与[性能测试误差对比研究(二)](https://mp.weixin.qq.com/s/8oq9rSyCgxAiQAYrhHUCkg)相同,原因不赘述了。

    JsonPath

    这里一种解析JSON格式数据的方式,好些测试框架都有类似的设计,我知道的rest assured就是使用这种方式,可以说非常好用。我之前也对这个JsonPath框架进行过讲解以及用Groovy特性进行封装。有文为证:

    这里我采用了JsonPath实践(一)中官方Demo中的JSON数据。脚本改造如下:

            @Override
            void run() {
                times.times {
                    def start = Time.getTimeStamp()
                    sleep(0.05 )
                    def instance = JsonUtil.getInstance(json)
                    instance.get("$.store.book[0].author")
                    def end = Time.getTimeStamp()
                    excutetimes.getAndIncrement()
                    costs.add(end - start)
                }
                countDownLatch.countDown()
            }
    

    依然采取20线程,50次执行。预期的QPS应该是400。

    INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16
    INFO-> 通过平均时间计算QPS:357.7625529936
    INFO-> 通过总时间计算QPS:349.7726477789
    INFO-> 误差是:2.23%
    
    Process finished with exit code 0
    

    下面40线程,50次执行的结果,这次QPS的预期应该是800:

    INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16
    INFO-> 通过平均时间计算QPS:719.392113664
    INFO-> 通过总时间计算QPS:702.7406886859
    INFO-> 误差是:2.31%
    
    Process finished with exit code 0
    
    

    误差保持稳定,距离预期的误差也是比较稳定的。下面进行40线程,100次执行。预期依然是800QPS。结果如下:

    INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16
    INFO-> 通过平均时间计算QPS:737.4869211304
    INFO-> 通过总时间计算QPS:729.527630859
    INFO-> 误差是:1.08%
    
    Process finished with exit code 0
    
    

    误差减少,距离期望值居然减少了,应该是运行越来越快的Java热点代码的原因。

    正则

    这个比较简单了,正则是最常用的一种验证,提取数据的方式。这个依然采用上一个的JSON字符串,增加类变量static String jsonstr = json.toString()。方法改造如下:

            @Override
            void run() {
                times.times {
                    def start = Time.getTimeStamp()
                    sleep(0.05)
                    Regex.isRegex(jsonstr, /0-d{3}-d{5}-/)
                    def end = Time.getTimeStamp()
                    excutetimes.getAndIncrement()
                    costs.add(end - start)
                }
                countDownLatch.countDown()
            }
    

    下面是20线程,50次执行的结果:

    INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16
    INFO-> 通过平均时间计算QPS:370.6930105833
    INFO-> 通过总时间计算QPS:361.0108303249
    INFO-> 误差是:2.61%
    
    Process finished with exit code 0
    

    误差相对其他也不多,但是距离预期400的QPS,要比JsonPath接近了很多。下面试试40线程,50次请求。

    INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16
    INFO-> 通过平均时间计算QPS:739.8638650488
    INFO-> 通过总时间计算QPS:721.240533718
    INFO-> 误差是:2.52%
    
    Process finished with exit code 0
    

    结果跟JsonPath还是非常接近的,误差比较稳定,相比JsonPath是比较大的,距离预期QPS误差是稳定的。下面是40线程,100次执行:

    INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16
    INFO-> 通过平均时间计算QPS:750.0328139356
    INFO-> 通过总时间计算QPS:741.1524921253
    INFO-> 误差是:1.18%
    
    Process finished with exit code 0
    
    

    误差有大幅下降,距离期望QPS有所增加,基本符合经验值。

    异常

    这个在实际中遇到情况不多,一般如果出现异常不是HTTP协议的异常就是业务验证失败导致的。出现这两个的话,应该需要收集线索,准备排查问题了。

    方法搞在如下:

            @Override
            void run() {
                times.times {
                    def start = Time.getTimeStamp()
                    sleep(0.05)
                    try {
                        if (getRandomInt(3) == 1) fail()
                    } catch (e) {
    
                    }
                    def end = Time.getTimeStamp()
                    excutetimes.getAndIncrement()
                    costs.add(end - start)
                }
                countDownLatch.countDown()
            }
    

    老规矩先跑一下20线程,50次执行,预期QPS是200:

    INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16
    INFO-> 通过平均时间计算QPS:373.9016638624
    INFO-> 通过总时间计算QPS:360.7503607504
    INFO-> 误差是:3.52%
    
    Process finished with exit code 0
    
    

    误差已经相比前两个因素大了一些,距离预期值倒是很接近,说明异常处理还是挺快的。下面是40线程,50次执行:

    INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16
    INFO-> 通过平均时间计算QPS:753.1396509198
    INFO-> 通过总时间计算QPS:733.137829912
    INFO-> 误差是:2.66%
    
    Process finished with exit code 0
    
    

    误差有所降低,其他指标跟前两者一致。也是这些处理事项的通病。下面试试40线程,100次执行,预期应当是误差降低,QPS距离预期稳定:

    INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16
    INFO-> 通过平均时间计算QPS:757.9130863168
    INFO-> 通过总时间计算QPS:743.9092430723
    INFO-> 误差是:1.85%
    
    Process finished with exit code 0
    
    

    符合预期,哈哈!

    看来异常处理对于性能的影响还是偏小的,平时能遇到的异常可能比较少。之前我还担心,现在觉得的确是多虑了。

    • 这个系列终于完结了!!!

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

  • 相关阅读:
    JVM学习(2):类加载器
    JVM学习(1):类加载机制
    MySQL优化(7):其他注意事项
    MySQL优化(6):分表和读写分离
    MySQL优化(5):分区
    MySQL优化(4):查询缓存
    MySQL优化(3):索引
    关于博客
    【题解】Telephone Lines
    【题解】神经网络
  • 原文地址:https://www.cnblogs.com/FunTester/p/14781066.html
Copyright © 2020-2023  润新知