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

最新推荐文章于 2024-09-14 17:03:27 发布

_Rye_

最新推荐文章于 2024-09-14 17:03:27 发布

阅读量1.1k

点赞数 18

分类专栏：性能测试文章标签：趋势分析

本文链接：https://blog.csdn.net/qq_37756660/article/details/136615225

版权

性能测试专栏收录该内容

33 篇文章 13 订阅

订阅专栏

本文通过实际案例探讨了前端性能测试中如何关注TPS、响应时间和错误率，重点讲解了Ramp-up配置的作用以及如何通过趋势分析找出问题。案例中，TPS波动过大影响了分析，提示我们需要对性能曲线的合理性敏感，调整参数以优化性能。

摘要由CSDN通过智能技术生成

在性能分析中，前端的性能工具，我们只需要关注几条曲线就够了：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;

JMeter 脚本关键部分：

<stringProp name="ThreadGroup.num_threads">100</stringProp>
//我们来看这里，ramp_time只有1秒，意味着线程是在1秒内启动的，这种场景基本上都和真实的生产场景不相符。
<stringProp name="ThreadGroup.ramp_time">1</stringProp>
<boolProp name="ThreadGroup.scheduler">true</boolProp>
<stringProp name="ThreadGroup.duration">300</stringProp>
...............
<CSVDataSet guiclass="TestBeanGUI" testclass="CSVDataSet" testname="CSV Data File Config" enabled="true">
  <stringProp name="delimiter">,</stringProp>
  <stringProp name="fileEncoding">utf-8</stringProp>
  <stringProp name="filename">filename</stringProp>
  <boolProp name="ignoreFirstLine">false</boolProp>
  <boolProp name="quotedData">false</boolProp>
  <boolProp name="recycle">true</boolProp>
  <stringProp name="shareMode">shareMode.all</stringProp>
  <boolProp name="stopThread">false</boolProp>
  <stringProp name="variableNames">url</stringProp>
</CSVDataSet>

在这个脚本中，逻辑非常简单，一个 RPC 接口：1. 发出请求；2. 返回响应；3. 打印返回信息。

本机跑出来的结果如下：

在这个案例中，参数化数据就是根据真实的业务量来计算的，这个可以肯定没有问题。

那么架构呢？在最上面的图中已经有了部署的说明。在逻辑实现上，也就是一个很简单的服务端，内部并没有复杂的逻辑。所用到的监控工具是 top、Vmstat。

看了哪些计数器呢？CPU、内存、I/O 等。

下面我们开始分析。

第一阶段

对公网上的测试来说，基本上压力都会在网络上，因为出入口带宽会成为瓶颈，所以先要看一眼自己的带宽用到了多少，再比对一下出口路由上的带宽。

这里 1Gbps 只用到了 0.01%，也就是 (1000/8)x0.01%=12.5k（这里是将带宽 bit 换成 byte 计算）。

在这样的带宽使用率之下，即使是公网也不见得会有问题，更别说在内网了。可见带宽不是瓶颈点。

既然这样，我们直接在内网里来做分析，看原因是什么。

但是我们要以什么样的场景来跑呢？因为带宽现在看到用得并不多，但 TPS 也上不去。首先应该想到的场景就是把 TPS 曲线给做出梯度来。

为什么要这么做？最重要的就是要知道到底 TPS 在多少压力线程下会达到最大值，也就是我在各种场合经常强调的一个场景，最大 TPS 场景。关于这种曲线，我们不需要性能指标应该就可以做得出来。如下图所示：

在一个既定场景、既定数据、既定环境的压力场景中，我们一定要拿到这样趋势的 TPS 和 RT 曲线。其中绿色和红色的点都是不需要业务指标来限定的，而是通过压力场景中观察 TPS 趋势线来确定。

解读一下这个趋势图：

1. 响应时间一定是从低到高慢慢增加的；

2. TPS 一定也是从低到高慢慢增加的，并且在前面的梯度中，可以和线程数保持正比关联。举例来说，如果 1 个线程 TPS 是 10，那 2 个线程的 TPS 要在 20。依次类推。

而在这个例子中，前面有提到 100 线程 1 秒加载完，这样的比例完全看不出来梯度在哪，所以，改为 100 秒加载 100 个线程，再来看看梯度。

测试结果如下：

从这个结果可以看出几点：

1.TPS 一点梯度没看出来。为什么说没有看出来呢？这里我发一个有明显梯度的 TPS 曲线出来以备参考（这张图不是本实例中的，只用来做分析比对）：

2. 响应时间增加的太快了，明显不符合前面我们说的那个判断逻辑。那什么才是我们判断的逻辑呢？这里发一个有明显梯度的出来以备参考（这张图不是本实例中的，只用来做分析比对）：

1. 粒度太粗，对一个 duration 只有五分钟的场景来说，这样的粒度完全看不出过程中产生的毛刺。

2. 至少看到内网的 TPS 能到 180 了，但是这里没有做过其他改变，只是把 Ramp-up 放缓了一些，所以我觉得这个案例的信息是有问题的。

第二阶段

针对以上的问题，下面要怎么玩？我们列一下要做的事情。

1. 将 Ramp-up 再放缓，改为 300 秒。这一步是为了将梯度展示出来。

2. 将粒度改小，JMeter 默认是 60 秒，这里改为 1 秒。这一步是为了将毛刺显示出来。强调一点，如果不是调优过程，而是为了出结果报告的话，粒度可以设置大一些。至于应该设置为多大，完全取决于目标。

接着我们再执行一遍，看看测试结果：

这样看下来，有点意思了哈。明显可以看到如下几个信息了。

1. 响应时间随线程数的增加而增加了。

2. TPS 的梯度还是没有出来。

显然还是没有达到我们说的梯度的样子。但是这里我们可以看到一个明显的信息，线程梯度已经算是比较缓的了，为什么响应时间还是增加得那么快？

这里的服务器端压力情况呢？如下所示：

从监控图大概看一下，服务端 CPU、内存、网络几乎都没用到多少，有一种压力没有到服务端的感觉。

在这一步要注意，压力在哪里，一定要做出明确的判断。

在这里，当我们感觉服务端没有压力的时候，一定要同时查看下网络连接和吞吐量、队列、防火墙等等信息。查看队列是非常有效的判断阻塞在哪一方的方式。

如果服务端的 send-Q 积压，那就要查一下压力端了。如下所示：

State       Recv-Q Send-Q                      Local Address:Port                                     Peer Address:Port
......
LISTEN      0    54656                                    :::10001                                               :::*
......

在网络问题的判断中，我们一定要明确知道到底在哪一段消耗时间。我们来看一下发送数据的过程：