如何做性能测试

上周参与了一个项目其中的性能测试的部分,发现了一些问题,也在做的过程中学到了一些知识。

起因是整个epic是在做整体的优化,需要在测试环境(旧版本)做一个baseline的测试,再将测试环境刷到最新版本再做一次测试进行比对数据结果。

1 待优化的地方

整个执行过程虽然有同事的帮助,但也是自己要遇到一些麻烦:

  • 测试过程中没有记录跳板机的机器性能,即CPU内存占用等数据,是事后根据测试的时间去翻了一些日志大概捞回了一些数据。缺少这个数据的话其实是对整个系统的性能缺少一定的描述。只有latency这种数据并不足以支撑描述。比如我的系统可以处理10000个请求或者tps非常高,但是系统资源却被用爆了,这样的情况也是相对不可取的。
  • 对于测试脚本的数据定义没有很精确,没有研究线上的用户数据来确定实际的操作步骤,有点倾向于“拍脑门”。

2 比较好的地方

做的比较好的点是在于:

  • 测试结果并不是只有average的数据,通过awk这个工具,我们获取到了P50,P75,P90,P99的数据,以及MAX和MIN。举个例子来说,一个地方平均收入并不低但是可能贫富差距大,大部分财富集中在少数人手里,依然是穷人多。同理,平均的latency可能不是很立体的展示性能数据。P50就是说50%的request落在了某个时间之内。要看大多数的latency时间才相对有意义。
  • 通过脚本自动执行模拟了用户操作。通过写进lua脚本或者shell脚本,模拟了用户的常见操作,减少了出错的概率。当然此处也提到了,模拟操作的次数和复杂度并没有完全调研线上比较真实的操作。
  • 脚本还输出了每一条测试用例的成功率。这点很好理解,如果case都失败了,很多超时的请求,那测试的数据其实不置信。

3 如何严谨地做性能测试

此文也是收到了陈皓老师的影响,所以想直接参考他对于性能测试的理解和指导:

一般来说,性能测试要统一考虑这么几个因素:Thoughput吞吐量Latency响应时间资源利用(CPU/MEM/IO/Bandwidth…),成功率系统稳定性

下面的这些性能测试的方式基本上来源自我的老老东家汤森路透,一家做real-time的金融数据系统的公司。

一,你得定义一个系统的响应时间latency,建议是TP99,以及成功率。比如路透的定义:99.9%的响应时间必需在1ms之内,平均响应时间在1ms以内,100%的请求成功。
如何定义这个latency?
二,在这个响应时间的限制下,找到最高的吞吐量。测试用的数据,需要有大中小各种尺寸的数据,并可以混合。最好使用生产线上的测试数据。

三,在这个吞吐量做Soak Test,比如:使用第二步测试得到的吞吐量连续7天的不间断的压测系统。然后收集CPU,内存,硬盘/网络IO,等指标,查看系统是否稳定,比如,CPU是平稳的,内存使用也是平稳的。那么,这个值就是系统的性能

四,找到系统的极限值。比如:在成功率100%的情况下(不考虑响应时间的长短),系统能坚持10分钟的吞吐量。

五,做Burst Test。用第二步得到的吞吐量执行5分钟,然后在第四步得到的极限值执行1分钟,再回到第二步的吞吐量执行5钟,再到第四步的权限值执行1分钟,如此往复个一段时间,比如2天。收集系统数据:CPU、内存、硬盘/网络IO等,观察他们的曲线,以及相应的响应时间,确保系统是稳定的。

六、低吞吐量和网络小包的测试。有时候,在低吞吐量的时候,可能会导致latency上升,比如TCP_NODELAY的参数没有开启会导致latency上升(详见TCP的那些事),而网络小包会导致带宽用不满也会导致性能上不去,所以,性能测试还需要根据实际情况有选择的测试一下这两咱场景。

(注:在路透会用第二步得到的吞吐量乘以66.7%来做为系统的软报警线,80%做为系统的硬报警线,而极限值仅仅用来扛突发的peak)

4 瓶颈排查思路与QPS的计算

  • QPS 如何计算?

    • QPS = 并发/RT(response time), 也即并发=QPS*RT。

        • 压测找瓶颈就是加并发然后看哪个节点RT增加多,就是哪里有瓶颈。

          • 如何算最大QPS

            img
          • 如何获取cpu time 和 wait time

            Tomcat 调用 MySQL,发去SQL到接收到查询结果这个时间对Tomcat就是wait time。Tomcat处理一个请求需要100ms,其中调用MySQL 需要10ms,那么cpu time 90ms, wait time 10ms。

          • 如何获取最佳线程数(最好的并发数)。

            最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间)* cpu数量。刚好消耗完服务器瓶颈资源的临界线程数。当最大QPS的时候, 增加并发也会增加RT。

      • 一个机器如果需要消耗10ms,其中9ms是CPU调用查DB,那么这个请求需要消耗CPU 1ms,那实际QPS=1000, 8核机器理论支持最大QPS为8000。

  • 压测前先用一个并发压,一个并发的假设是没有任何锁、竞争,跑出来的rt就是最佳rt,手机RT,QPS,CPU数据;计算得到总QPS、最佳并发线程数;然后加并发,CPU跑满前rt不应该增加太多(理想状况下)。这期间加并发哪里rt增加快瓶颈就在哪里。

5 参考

如何做性能测试
一文搞懂高并发性能指标:QPS、TPS、RT、吞吐量
一次春节大促性能压测不达标的瓶颈推演