性能测试之TPS趋势分析(三)

理解TPS趋势分析

   在性能分析中,前端性能工具,我们只需要关注几条曲线就够了:TPS、响应时间和错误率。这是我经常强调的。

   但是关注TPS到底应该关注什么内容,如何判断趋势,判断了趋势之后,又该如何做出调整,调整之后如何定位原因,这才是我们关注TPS的一系列动作。

   今天,我们通过一个实际的案例来解析什么叫TPS的趋势分析。

案例描述

  这是一个案例,用一个2C4G的Docker容器做服务器。结构简单至极,如下图所示:

性能测试之TPS趋势分析(三)

  当个人电脑(上图中的压力工具1)测试云端服务器时,达到200多TPS。但是当用云端同网段压力机(上图中压力工具2)测试时,TPS只有30多,并且内网压力机资源比本地压力机资源要高出很多,服务器资源也没有用完。

在这样的问题面前,期通常都会有一堆的问题要问。

  1. 现象是什么
  2. 脚本是什么
  3. 架构是什么
  4. 用了那些监控工具
  5. 看了那些计数器

在分析之前,这些问题都是需要收集的信息,而实际上在分析过程中,我们会发现各种数据的缺失,特别是远程分析的时候,对方总是不知道应该给出什么数据。

我们真多这个案例实际说明一下。

这个案例的现象是TPS低,资源用不上。

下面是一个RPC脚本的主要代码部分。

 性能测试之TPS趋势分析(三)

JMeter脚本关键部分

 性能测试之TPS趋势分析(三)

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

本机跑出来的结果如下:

 性能测试之TPS趋势分析(三)

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

  那么架构呢?在最上面的图中已经有了部署的说明。在逻辑实现上,也就是一个很简单的服务端,内部并没有复杂的逻辑。所用到的监控工具是top、Vmstat。看了CPU、内存、I/O等计数器。

下面我们开始分析。

第一阶段

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

 性能测试之TPS趋势分析(三)

这里1Gbps只用到了0.01%,也就是(1000/8)*0.01%=12.5k(这里是将带宽bit换成byte计算)

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

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

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

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

性能测试之TPS趋势分析(三) 

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

我来解读一下这个趋势图:

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

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

测试结果如下:

 性能测试之TPS趋势分析(三)

性能测试之TPS趋势分析(三)

 

 性能测试之TPS趋势分析(三)

从结果中可以看出几点:

  1. TPS梯度一点也没看出来。为什么说没看出来?这里我发一个有明显梯度的TPS曲线出来以备参考(这张图不是本实例中的,只是用来作分析比对):

 性能测试之TPS趋势分析(三)

    2、响应时间增加的太快了,明显不符合前面我们说的那个判断逻辑。那什么才是我们判断的逻辑呢?这里我发一个明显梯度的出来以备参考(这张图不是本实例中的,只是用来作分析比对):

 性能测试之TPS趋势分析(三)

  1. 粒度太粗,对一个duration只有5分钟的场景来说,这样的粒度完全看不出过程中的毛刺。
  2. 至少看到内网的TPS能到180了,但是这里没有做过其它改变,只是把Ramp-up放缓了一些,所以我觉得这个案例的信息是有问题的。

第二阶段

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

  1. 将Ramp-up再放缓,改为300秒。这一步是为了将梯度展示出来。
  2. 将粒度改小,JMeter默认是60s,这里改为1秒。这一步是为了将毛刺显示出来。

强调一点,如果不是调优过程,而是为了出结果报告的话,粒度可以设置大一些。至于应该设置为多大,完全取决于目标。

接着我们再执行一遍,看看测试结果:

 性能测试之TPS趋势分析(三)

性能测试之TPS趋势分析(三)

 

 性能测试之TPS趋势分析(三)

 

 

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

  1. 响应时间随着线程的增加而增加了。
  2. TPS梯度还是没有出来。

显然还是没有达到我们说的梯度的样子。但是这里我们可以看到一个明显的信息,线程梯度已经算是比较缓的了,为什么响应时间还是增加的那么快?这时的服务端压力情况是怎样的呢?如下所示:

 性能测试之TPS趋势分析(三)

 

 

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

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

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

如果服务端的send – Q积压,那就要查一下压力端了。如下所示:

 性能测试之TPS趋势分析(三)

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

 性能测试之TPS趋势分析(三)

 

 

从上图可以看出,发送数据是数据是先放到tcp_wmem缓存中,然后通过tcp_transmit_skb()放到TX  Queue中,然后通过网卡的环形缓冲区发出去。而我们看到的send – Q就是Tx队列了。

查看压力端脚本,发现一个问题。

 性能测试之TPS趋势分析(三)

一般情况下,我们在调式脚本的时候会打印日志,因为要看到请求和响应都是什么内容。但是压力过程中,基本上我们都会把日志关掉。一定要记住这一点,不管是什么压力工具,都要在压力测试中把日志关掉,不然TPS会受到很严重的影响。

了解JMeter工具的都知道-n参数命令行执行,并且不打印详细的返回信息的。但是这里,一直在打印日志,并且这个日志在JMeter中执行时加了-n参数也是没用的。

这样一来,时间全消耗在打印日志中了。知道这里就好办了。我们在这里做两件事情:

  1. 把打印日志这一行代码注释掉,再执行一遍。
  2. 把ramp – up时间增加到600秒。

为什么我要执着于把ramp – up时间不短增加?在前面也有强调,就是要知道TPS和响应时间曲线的趋势。

在性能分析过程中,我发现有很多性能工程师,都是看平均值、最大值、最小值等等这些数据,并且也只是描述这样的数据,对曲线的趋势一点也不敏感。这是完全错误的思路,请注意,做性能分析一定要分析曲线的趋势,通过趋势的合理性来判断下一步要做的事情。

什么叫做对曲线的趋势敏感?就是要对趋势做出判断,并且要控制曲线的趋势。

有时,我们经常会看到TPS特别混乱的曲线,像前面发的TPS图一样,抖动夫妇非常大,这种情况就是完全不合理的,在遇到这种情况时,一定要记得降低压力线程。

你可能会问,降多少呢?这里会有一个判断的标准,就是一直降到TPS符合我们前面看到的那个示意图为止

再给你一个经验,如果实在不知道降多少,就从一个线程开始递增,直到把梯度趋势展示出来。

第三阶段

通过注释掉打印日志代码,可以得到如下结果:

 性能测试之TPS趋势分析(三)

性能测试之TPS趋势分析(三)

 

 性能测试之TPS趋势分析(三)

从TPS曲线上可以看到,梯度已经明显出来了。再有一个用户的时候,一秒就能达到1000多TPS,并且在持续上升;两个线程时达到2500以上,并且也在直线上升的。

从响应时间来看,也是符合这个趋势的,前面都在1ms以下,后面慢慢变长。

压力越大,曲线的毛刺就会越多,所以在TPS达到6000以后,后面的TPS在每增加一个线程,都会出现强烈的抖动。

在这种情况下,我们再往下做,有两条路要走,当然这取决于我们的目标是什么。

  1. 接着加压,看系统什么时候崩溃。做这件事情的目标是找到系统的崩溃点,在以后避免出现。
  2. 讲线程最大值设置为10,增加ramp – up的时间,来看一下更明确地递增梯度,同事分析在线程增加过程中,系统资源分配对TPS的影响,以确定线上应该做相对应的配置。

总结

在这个案例中,我们将TPS从150多调到6000以上,就是因为一句日志代码。

我分析过非常多的性能案例,到最后发现,很多情况都是由各种简单的因素导致的,这一反差也会经常让人为这一路分析的艰辛不值得。

但我要说的是,性能分析就是这样,当你不知道问题在哪里的时候,有一个思路可以引导着你走向最终的原因,那才是最重要的。

我希望通过本文可以让你领悟到,趋势这个词对曲线分析的重要性。在本文中,我们通过对曲线的不合理性做出判断,你需要记住以下三点:

  1. 性能分析中,TPS和响应时间的曲线是要有明显的符合逻辑趋势的。如果不是,则要降线程,增加ramp – up来让TPS趋于平稳
  2. 我们要对曲线的趋势敏感,响应时间的增加不可以过于陡峭,TPS的增幅在一开始要和线程数对应。
  3. 当TPS和响应时间曲线抖动过于强烈,要想办法让曲线平稳下来,进而分析根本原因,才能给出线上的建议配置。

思考题

ramp – up配置有设么样的作用?

为什么说压力工具中TPS和响应时间曲线抖动过大会不宜与分析?

 

 

Ramp-up 配置有什么样的作用?
答:Ramp-up 配置的时间是指启动所有配置的线程总数所用的时间,例如设置的线程总数为500,Ramp-up设置的时间为50s,意为:启动500个线程数需要50s,平均为每一秒启动10个线程
为什么说压力工具中 TPS 和响应时间曲线抖动过大会不易于分析?
答:性能分析一定要分析曲线的趋势,通过趋势的合理性来判断性能瓶颈所在的原因,光靠平均值、最大值、最小值、中位数是无法确切的分析处压测过程中服务器的具体情况,只有通过分析曲线趋势,增加对趋势的敏感程度才是压测过程中更好的保障和前提。

上一篇:压力测试TPS上不去,但是系统资源又很清闲


下一篇:OpenCV与QT联合编译 分类: Eye_Detection ZedBoard OpenCV shell ubuntu 2014-11-08 18:54 143人阅读 评论(0) 收藏