26丨案例：手把手带你理解TPS趋势分析

高楼



该思维导图由 AI 生成，仅供参考

在性能分析中，前端的性能工具，我们只需要关注几条曲线就够了：TPS、响应时间和错误率。这是我经常强调的。
但是关注 TPS 到底应该关注什么内容，如何判断趋势，判断了趋势之后，又该如何做出调整，调整之后如何定位原因，这才是我们关注 TPS 的一系列动作。
今天，我们就通过一个实际的案例来解析什么叫 TPS 的趋势分析。
案例描述这是一个案例，用一个 2C4G 的 Docker 容器做服务器。结构简单至极，如下所示：
当用个人电脑（上图中压力工具 1）测试云端服务器时，达到 200 多 TPS。但是当用云端同网段压力机（上图中压力工具 2）测试时，TPS 只有 30 多，并且内网压力机资源比本地压力机要高出很多，服务器资源也没有用完。
在这样的问题面前，我通常都会有一堆的问题要问。
现象是什么？
脚本是什么？
数据是什么？
架构是什么？
用了哪些监控工具？
看了哪些计数器？
在分析之前，这些问题都是需要收集的信息，而实际上在分析的过程中，我们会发现各种数据的缺失，特别是远程分析的时候，对方总是不知道应该给出什么数据。
我们针对这个案例实际说明一下。
这个案例的现象是 TPS 低，资源用不上。
下面是一个 RPC 脚本的主要代码部分。
public SampleResult runTest(JavaSamplerContext arg0) {
    // 定义results为SampleResult类
    SampleResult results = new SampleResult();
    // 定义url、主机、端口
    String url = arg0.getParameter("url");
    String host = arg0.getParameter("host");
    int port = Integer.parseInt(arg0.getParameter("port"));
    results.sampleStart();
    try {
        message=detaildata_client.detaildata_test(url);// 访问URL并将结果保存在message中
        System.out.println(message); //打印message，注意这里
        results.setResponseData("返回值："+ message, "utf-8");
        results.setDataType(SampleResult.TEXT);
        results.setSuccessful(true);
    } catch (Throwable e) {
        results.setSuccessful(false);
        e.printStackTrace();
    } finally {
        String temp_results=results.getResponseDataAsString();
        results.setResponseData("请求值："+arg0.getParameter("url")+"\n"+"返回值:"+temp_results, "utf-8");
        results.sampleEnd();
    }
    return results;

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文深入探讨了通过TPS（每秒事务处理量）的趋势分析进行性能分析的方法和重要性。通过一个具体案例，详细介绍了如何观察TPS和响应时间曲线，确定最大TPS场景，并分析系统资源分配对TPS的影响。作者强调了对曲线趋势的敏感性，指出在性能分析中，TPS和响应时间的曲线应该呈现明显的合逻辑的趋势，对于抖动过大的曲线要采取措施使其平稳下来。文章还提出了一些思考题，引导读者深入思考和交流。通过本文，读者可以了解到如何通过观察TPS和响应时间曲线来判断性能问题，以及如何确定最大TPS场景。文章内容深入浅出，对于需要进行性能分析和优化的技术人员具有很高的实用价值。值得一读。文章通过具体案例分析，深入浅出地介绍了TPS趋势分析的方法和重要性。读者可以从中了解到如何通过观察TPS和响应时间曲线来判断性能问题，并学习到如何确定最大TPS场景。这对于需要进行性能分析和优化的技术人员具有很高的实用价值。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《性能测试实战 30 讲》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(31)

最新
精选

大拇哥
Ramp-up 配置有什么样的作用？答：Ramp-up 配置的时间是指启动所有配置的线程总数所用的时间，例如设置的线程总数为500，Ramp-up设置的时间为50s,意为：启动500个线程数需要50s，平均为每一秒启动10个线程为什么说压力工具中 TPS 和响应时间曲线抖动过大会不易于分析？答：性能分析一定要分析曲线的趋势，通过趋势的合理性来判断性能瓶颈所在的原因，光靠平均值、最大值、最小值、中位数是无法确切的分析处压测过程中服务器的具体情况，只有通过分析曲线趋势，增加对趋势的敏感程度才是压测过程中更好的保障和前提。
作者回复: 理解到位，已经出师。
2020-02-22

13
Geek_6a9aeb
 老师，你这里压力工具1是公网，压力工具2是内网，为何内网的TPS反而低，公网的反而快，按普通理解内网的网速是最快的啊，为何网速快反而TPS低？
作者回复: 因为内网TPS上的快，而场景又设置的线程增加太快，所以导致了tps看起来是低的，实际上已经是压死之后的状态了。
2021-02-03

11
Geek_6a9aeb
这篇文章给人没有写完整的感觉，最好TPS上去了，也没提服务端有没积压的数据，以及cpu 内存这些大的指标有没提升？实际操作很难得到完美的TPS幅度曲线，都有一点波动，还有后面TPS曲线有了之后，就没有完整的描述到定位到是打印耗费时间多？如果是有经验的人可能会一下子定位到打印问题
作者回复: 看下一个专栏吧。会有相似的案例。
2021-01-30
3
4
Geek_6a9aeb
当用个人电脑（上图中压力工具 1）测试云端服务器时，达到 200 多 TPS。但是当用云端同网段压力机（上图中压力工具 2）测试时，TPS 只有 30 多，并且内网压力机资源比本地压力机要高出很多，服务器资源也没有用完。老师，下面又说是日志打印，那最先的TPS差异是因为打印吗？
作者回复: 这里有两个问题：1，是在内网测试时网络快，所以资源使用的会高；2，在本地压力机里由于网络不够快，日志打印的问题没有突显出来，在内网中才体现出来。
2021-01-30
2
4
蔡森冉
今天好像明白一些东西，发现自己之前好像是一直是错的（好像一直理解这个都错了），就是Ramp-up是启动所有线程的时间，但是只是启动，实际上所有线程启动后压力时间是Duration，可以这样理解吗？然后tps抖动过大，那其实中间值这些数据就是完全没有意义的。
作者回复: duration包括rampup。抖动的tps就是要分析的内容，不是没意义。
2020-03-25

4
🌻Naomi
TPS的趋势是否应该跟线上流量分布一致？
作者回复: 应该，这个说法方向最正确。
2020-03-03

4
涵涵
老师，请教2个问题 1、参数化数据的时候是读取文件比较合适，还是读取数据库数据比较合适？ 2、BeanShell取样器中对请求数据进行加签加密处理，会对测试结果有影响吗？
作者回复: 1. 看数据量，太大的参数化数据放在文件中读取慢的时候，就要考虑用数据库或缓存了。 2. 会有影响。不过根据业务逻辑，如果客户端也是必须做加签加密的，也是必须要在脚本中处理的。这也是符合真实业务逻辑的。
2021-07-30
3
3
Geek_6a9aeb
第三阶段通过注释掉打印日志的代码，可以得到如下结果：仔细看这个阶段第二个图的标识，不是TPS，而是hit s，这有点偷换概念了吧？
作者回复: 在每个http request为一个T的情况下，这是同样的含义。
2021-01-30
2
3
cathy
老师好，老师讲的都是通过压出梯度来确定并发数，想跟老师确认一下以下做法是正确的吗：使用jmeter，然后设置集合点（同步定时器），大量的线程数（几百个），循环次数设为1，来做瞬间一次性并发，看看系统能不能承受住，如果没报错并且响应时间可接受，就说可以支持几百个并发
作者回复: 不正确。
2020-08-04
2
3
zwm
Ramp-up 配置有什么样的作用？为什么说压力工具中 TPS 和响应时间曲线抖动过大会不易于分析？（1）ramp-up就是线程启动时间。比如10个线程120s基本就是梯度加压 5个线程运行60s之后再启动50线程运行，是否停止要看是否设置循环等，是一个等比例的梯度加压。（2）曲线抖动过大，可以肯定会有异常，这个题确实不会做
作者回复: 曲线抖动大了，不容易分析异常和趋势之间的关系。
2020-03-06

3

收起评论