性能测试基础概念1

Posted 2023-05-18

参考技术A

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值
步骤：

在线用户数、并发用户数、压力线程数、TPS的关系如下：

1.单个用户的TPS计算：通过日志，拉取一个用户的操作记录，记录下来一个事务的操作时间。例如：1个用户，100秒内，完成了一个完整流程，有4个操作（查询商品、填写信息、支付、订单详情），调用了20个接口。
用户级TPS：1 1/100=0.01TPS。 (1个用户) （1个完成业务）/100s
操作级： 1 4/100=0.04 TPS. (1个用户) （4个操作）/100s
接口级： 1 20/100=0.2TPS (1个用户) （20个接口）/100s

2.多用户的TPS。从生产拉取1天的用户量，记算下平均完成的时间（这会有一个问题就是很多用户没有真实走完一个完整业务，所以这个TPS计算是要注意？为了方便仅做假设每个用户是在100秒内完成）假如有一100万的用户，在1天内完成业务
用户级TPS：1000000 1 1/24/60/60=11.57TPS。 1000000 (1个用户) （1个完成业务）/24小时/60分钟/60秒
操作级： 1000000 1 4/24/60/60=46.29 TPS. 1000000* (1个用户) （4个操作）/24小时/60分钟/60秒
接口级： 1000000 1 20/24/60/60=231.48TPS 1000000 (1个用户)*（20个接口）/24小时/60分钟/60秒

3.峰值时的TPS。 1000人，在1分钟内完成业务
用户级TPS：1000 1 1/60=16.67TPS。 1000 (1个用户) （1个完成业务）/60秒
操作级： 1000 1 4/60=66.67 TPS. 1000* (1个用户) （4个操作）/60秒
接口级： 1000 1 20/60=333.33TPS 1000 (1个用户)*（20个接口）/60秒

4,怎么计算并发用户数和TPS之间的关系。
假如在jmeter中，完成一个完整的流程5秒钟。
用户级TPS：1 1/5=0.2TPS。 (1个用户) （1个完成业务）/5s
操作级： 1 4/5=0.8 TPS. (1个用户) （4个操作）/5s
接口级： 1 20/5=4 TPS (1个用户) （20个接口）/5s

5,无停顿（并发用户）相当于多少有停顿的用户（在线用户）
0.2/0.01=20. 即无停顿TPS/有停顿TPS。
并发度=1/20*100% =5%

6.压力线程数
a)100万在1天内：1000000的在线TPS/并发TPS=11.57/0.2=57.85
b)1000在1分钟内： 1000的峰值TPS/并发TPS=16.67/0.2=83.35

7.并发用户数的计算
并发用户数=在线用户数×有停顿时间的单线程TPS/无停顿时间的单线程TPS

8.并发度：并发度=并发用户/在线用户×100%（取值要在同一时间段）

1.抽取业务模型，可以通过日志系统或埋点等手段获取。
2.业务模型的作用：一是评估线上的性能；二是为后面的容量测试做准备

也可称之为混合容量性能场景，即将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等的配合之下，分析瓶颈并调优的过程。
1，业务指标

2，对各业务进行基准性能场景测试，对各业务基线测试，并优化以满足业务性能指标
3，抽取线上业务模型
4，根据业务模型，编写执行脚本，进行容量测试

核心就是时长。在长时间的运行之下，观察系统的性能表现，分析瓶颈并调优的过程

1，根据实际的业务需求设置。如我们每周一个发布周期，平均2个月所有的业务线会发布一次（即服务器重启）。那么我们的稳定性测试的策略应该是以最大TPS，执行7~30天。不可少于7天。但可以多于30天。
2,为什么以容量测试的最大TPS？ 如果容量测试下来的最大TPS不能稳定执行，其容量测试的结果又什么意义？

性能测试基础概念

 不怕啰嗦的再次忠告，那想成为测试高手的新人，多学学基础知识。别把过多的时间放在研究新工具的使用上。工具何其多，原理差不多。不要本末倒置了。也算是自我提醒吧！

 

性能测试常见指标

 

     性能测试说白了就是通过工具模拟多个用户对被测系统进行访问。然后查看系统对于多个用户发来请求的处理能力。

     左边的两个小人表示两个用户，向右边服务器发送请求，然后得到服务器的响应信息。

    首先，我们要保证向服务器发送的请求的正确性，当然用户向服务器发送错误的请求，服务器也会个客户端响应信息，但响应的是报错信息；所以，为了保证测试数据的有效性，我们的要保证发送请求的正确性。

     为什么一般的性能测试要在局域进行？

     一般我们的性能测试都是在局域网中进行的。为什么一定要在局域网中进行呢？因为局域网中不受网络限制。这个说法不能绝对。但是一般测试工具的用户并发量是不会受到局域网带宽的限制，除非你做的是十万，百万级别的用户并发。相信懂一点网络知识的人都知道，当你上网很慢的时候，比如打开某某网站很慢，你肯定会骂电信的网络不给力，而不会骂这个网站响应速度不给力。因为，请求信息的耗时大部耗在传输过程中。

     所以，刚做测试时，我们群里热议论，如果我们每个人都开一个压力工具对百度网站进行加压。百度，服务器会不会挂掉。有测友说这样是不道德人。呵呵！其实，完全不必有这个担心。就一般人家用的带宽，我确保，你向百度服务器发送的请求大部分都死在半路上，就算不死到了百度服务器已经不能叫并发了。何况百度服务器的集群技术以及其他各种分压技术。所以，做性能测试不了解被测系统的架构，以及各种技术的性能。很难做出有效的测试报告。

下面我们看看性能测试的一些技术指标。  

Work Load = Virtual Users

工作负荷 = 虚拟用户数

     对服务器产生多大压力，可以由多少用户同时对服务器发送请求来衡量。也就是服务器的性能可以看它同时处理多少用户发送来的请求来衡量。

虚拟用户数可以用进程或线程的方式进行模拟。

 

response time  响应时间

       从客户端将数据包发出，到接收到服务器端发来的请求。这个过程的总体时间叫response time 

       这个时间用来衡量的处理请求的速度（抛出网速限制的前提下）

throughput ~Ti & To

       这个表示，吞吐量，吞吐量越大表示系统性能越强。1个用户跑100天和10个用户跑1分钟。当然是1个用户跑100天的吞吐量大。所以，我们要想看系统的性能应该用“吞吐率”，就是单位时间的吞吐量，比如吞吐量/秒。

      站在服务器端，T-in表示“吞”；T-out表求“吐”

Ti：T-in 主要衡量客户端的能力，看客户端往服务器发送的请求数据包的吞吐率。 

To： T-out 主要衡量的服务器端的能力，看服务器处理返回请求数据包的吞吐率。

Hits/Request

网页点击数/请求

Response/Successful Response

响应/成功的响应

     Request与Response是对应，一个请求对应一个响应。但当客户端对服务器的压力达到一直程度后，不是每一请求都能得到响应的。去年末火了个最牛B的“电子商务”网站。12306（铁路网上订票系统），虽然有很差的用户体验，但每天还是大把的人拼命的登录（过年回家的人伤不起），甚至用外挂登录。见有网友云云点击（请求）了几十几百次才订票（响应）成功。所以，成功响应率也是很重要的一个指标。客户端发送一千个请求的成功得到响应的几率。 

Hits Per Second 

每秒中点击次数

     和吞吐量一样，单单用点击数（hits）来衡量系统也是不合理的。所以，用每秒钟的点击数才能衡量出服务器的处理能力。

 

 

响应时间图分析

　　

横坐标表示用户数

纵坐标表示时间

 

红色虚线，表求的是一种系统的理想状态。

  当服务器处理10个用户请求时所用的时间是2秒（假设），当服务器处理200用户请求时所用的时间也是2秒。所以说这种状态是一种理想的状态。现实中，不管是如何超级强的服务器当用户数达到一定数量时，响应时间必会变慢。

 

蓝色斜线，是服务器常见的一种曲线状态。

    服务器的响应时间虽然用户数量的增加逐渐变慢。

当系统出现这种斜线，应该说系统性能是相当健壮的。随着用户的增长响应时间逐渐变长。

 

黑色曲线，个人觉得是服务器处理能力的真实曲线状态。

     为什么说黑线才是真实服务器处理能力的曲线呢？当用户处理一个用户请求是2秒（假设），当处两个用户请求是马上变成3秒（假设），当处理3个用户请求时变成4秒（假设）。再差的服务器也有个处理范围，比如是，100用户同时并发，服务器可以轻松应对，不管是10个用户还是80个用户同时请求，服务器都可以即可响应（请参考理发店模式）。只有当用户数量达到某个数量点后，服务器性能急剧下降。如上图黑色十字星处就是系统的拐角点。

      我们假设有一个门，在一个时间点上可同时过10个人，不管你是同时来3个还是10个都可以在同一时间点过门，假如来了11个人，必然有一个人要等10个人过门之后才能过。那么当超过10人来过门时，过门的速度就开始变慢。那么10就是服务器性能的拐角点。我们通常做压力测试找服务器的拐角点是很重要的任务之一。

     关蓝色曲线与黑色区线只是我们常见两种曲线。现实的测试中可能出现各种样式的曲线。当然还要看你做测试的细度，比如，10个用户是系统的拐点，如果你做完5个用户的一轮测试后，就是20用户的测试。那么画出来的曲线就变成斜线，拐点将被护忽略掉。

 

 

吞吐率图分析　　

横坐标虚拟用户数

纵坐标有吞吐率（服务器端）

 

红色虚线，表示一种理想的状态。

   随着用户数量的增加吞吐率也在持续增加。

 

黑色曲线，表示现实系统的吞吐率状态。

     刚开始吞吐率随着用户数量的增加逐渐变大，当大到一定程度时，逐渐平缓直到变成一条平线。

如果用户还在持续增加中，那么吞吐率有可能下降，直到系统挂掉。

     为什么会是这样呢？我们通过另一个例子来说，大家都在城市生活，相信上下班高峰期都会遇到堵车。在比较重要的红绿灯路口常会见到堵车现象。假如每个绿灯可以通过10辆，前期来三五辆车，遇到绿灯，一次都过去了。到了下班高峰期，车子变多，一下来了20辆，但这个路口的绿灯每天只能通过10辆，所以，这个时候，路口的通过率不会根据车辆的增加而继续增加。

    好的系统好像好有个好的交警在位置秩序，虽然车辆还在增加，但每个车辆都有条不紊等待通过路口。

    不好的系统如路口赶上交警拉肚子，车辆在增加，后面车辆等得不耐烦就往前挤，结果稿得互不相让。好嘛！之后还每个绿灯可通过10辆，现在只能有一辆车从夹缝中脱离苦海了。

    

    响应时间图与吞吐率图并不是我们一轮性能测试下来就能得到结果。需要经过多轮测试才能得到。设置不同的用户数量，得到每次的测试数据，将每次数据连接，从而得到最终系统性能曲线。关于用户数量每次增加的数量自己把握。如果，想精确，可以每次增加1个用户的方式来做，不过这样势必加大工作量，也没必要。这个需要每做完一轮测试后对数据进行分析，然后确定下轮测试所要设置的虚拟用户数。

 

      关于，性能指标的分析，就先谈到这里。关于内容，我反复经过思考，但难免有理解有误之处。还望高手点拨。共同进步。