10k

如何做性能测试 How To Do Performance Test

Published on

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

起因是整个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、吞吐量 [一次春节大促性能压测不达标的瓶颈推演](

Thoughts? Leave a comment