性能测试基础

性能的指标参数

名词解释

1. 线程数

能以线程式并发的方式，帮我们达成“短时间内向服务器发送大量请求”这一任务。

多线程式并发测试工具，顾名思义，会启动复数个线程，让每个线程独立向服务器端发出请求。

2. TPS Transactions Per Second（每秒传输的事物处理个数）

即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问.

一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

TPS的高低也会像木桶效应的影响与多种因素相关，当一处存在短板时会导致整个接口乃至系统的出现TPS上不去的情况。

3. 响应时间

从用户发送一个请求到用户接收到服务器返回的响应数据这段时间就是响应时间

关键路径：下图为一次http请求经过的路径，请求会经过网络发送到web服务器进行处理，如果需要操作DB，再由网络转发到数据库进行处理，然后返回值给web服务器，web服务器最后把结果数据通过网络返回给客户端

Response time = (N1+N2+N3+N4)+ (A1+A2+a3)，即：（网络时间 + 应用程序处理时间）
事务平均响应时间。
单个事务平均下来完成的速度越快，那么单位时间内能完成的事务数就越多，TPS就就越高

4. 95分位响应时间

请求数的响应时间从小到大排序后，剔除末端的百分之五的响应时间后得到的最高的响应时间称为95分位的响应时间，这样可以将瞬间的毛刺（尖峰）去掉，同时95分位与平均响应时间之差越小，表示系统的响应越趋于稳定

5. 请求错误个数

顾名思义：当前请求中出现的错误个数，可能是由于断言问题、服务器响应、资源丢失等问题造成的，常见的服务器响应码有404/500/502等，当出现错误个数我们可以调取jmeter的log来查看相应的报错日志。

常见的请求状态码

200：正确的请求返回正确的结果，如果不想细分正确的请求结果都可以直接返回200

301：请求成功，但是资源被永久转移。比如说，我们下载的东西不在这个地址需要去到新的地址。

400：请求出现错误，比如请求头不对等。

401：没有提供认证信息。请求的时候没有带上 Token 等。

403：请求的资源不允许访问。就是说没有权限。

404：请求的内容不存在。

500：服务器错误。代码有问题，需看下服务端代码

502：网关错误，多为配置了Nginx网关，未启动相应的服务

503：服务暂时不可用。服务器正好在更新代码重启。

6. 系统CPU使用率

使用率包含user（用户）和sys（系统），CPU使用率指的是程序在运行期间实时占用的CPU百分比，这是对一个时间段内CPU使用状况的统计。通过这个指标可以看出在某一个时间段内CPU被占用的情况。
在压测过程中user+sys的应控制在80%以下，高于80%服务器将存在一定的负载压力，服务器有瓶颈，导致压测结果不准。
top命令查看服务器CPU使用率和负载

7. 系统CPU负载

cpu负载是衡量一台服务器使用资源情况的提现，当负载越高时，服务器的压力越大。
如：一座桥上，没有车流量负载为0，为1时刚好满足桥面的正常通行，但是车流已经很堵了，如果到2到3则说明，桥已经堵的基本动不了了，车辆都停在次等待通行，cpu负载也如此，但是理想情况是满负载情况下的百分之70%。
如何计算服务器的负载？
grep 'model name' /proc/cpuinfo | wc -l
服务器的满负载是32，所以负载低于22.4属于正常，越高则可能影响到压测数据的分析。

8. 流量

流量的消耗包好进入服务器的流量和服务器往外部发送的流量，
进服务器的流量： 接口请求进入的流量，另外一方面 是从db/redis读取数据返回来的流量
出服务器的流量： 发起去读redis/mysql的语句，另外一方面就是服务器返回给压力机的返回结果流量
流量的高低可能会受服务器的带宽影响，当数据流量很大时，服务器已达到了最大带宽使用，会导致TPS无法继续增长的问题

性能瓶颈浅析（TPS无法提高）

1、网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。

2、连接池
可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。

3、垃圾回收机制
因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，回收如果较频繁，那么对TPS
也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。

4、数据库配置
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等

5、硬件资源
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。

6、压力机
比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题，一般情况单台够用）。

7、业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。

8、系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以、缓存过期、是否含有死锁等，都会影响到测试结果。

性能拐点图

图中有三条曲线，分别表示资源的利用情况

1. Utilization，包括硬件资源和软件资源
2. 吞吐量（Throughput，这里是指每秒事务数）
3. 响应时间（Response Time）。

图中坐标轴的横轴从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。

在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；
不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。
如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，但是吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。

当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。

根据此图可以知道，当性能出现瓶颈时往往伴随着响应时间的成倍增长和吞吐量的下降，在我们进行压测的过程中可以适当增加并发的线程数，来根据接口的响应时间和吞吐量的值来判断是否出现了性能瓶颈，当出现性能的瓶颈时我们可以根据前面所讲到的方式去观察服务器的资源使用情况，数据库连接池等配置来对接口进行分析

标签：负载,请求,并发,性能,基础,响应,TPS,测试,服务器
来源： https://www.cnblogs.com/icesugar/p/16073464.html