性能测试概述

为什么要进行性能测试？

1、企业需求

企业在业务有性能要求的情况下，我们进行性能测试的目的是为了验证软件，服务器的性能是否能满足未来的需求。

小问题：扩充机器是否能解决性能问题？

答：当然，它可以解决一定的问题，但是目前市场上云服务器的价格是比较高的，扩机的成本就很大了，并不是说所有服务都可以通过扩机来解决性能问题。良好的容量规划和性能调优才能解决问题

2、岗位需求

性能测试岗位薪资高，岗位也不少

普通的功能，自动化测试岗位面试，都会问大家，会不会性能测试

什么是性能测试？

性能测试就是利用自动化工具，对服务器进行评估的过程

1.评估方式：使用性能指标进行评估（响应时间，TPS，服务器资源占用率）

2.评估方向：硬件，架构设计，中间件，数据库，代码，操作系统，算法

3.中间件：指系统与系统之间连接的组件，包括tomcat，nginx，redis等

性能就是对网络中的请求所消耗的时间统计，分析消耗时间，时间损耗越小，效率越高，说明性能越好。进行性能测试，可以对所有时间进行验证

性能测试策略（分类）

常见性能测试策略

1、基准测试

2、负载测试

3、稳定性测试

4、其他：压力测试，并发测试，容量测试

基准测试

1.狭义：就是指通过工具，模拟单个用户，向服务器连续发送请求，记录服务器的性能测试指标。（其他环境不能改变，只能改变用户数量）

2.广义：通过固定大部分参数配置，来对服务器进行性你那个指标的收集，作为以后性能评估的一个参照

负载测试

定义：指对服务器进行负载的测试

负载：服务器挂的用户越多，负载就越高，就是指服务器挂的用户数量

注意：进行负载测试时，需要逐步增加用户数，来逐渐增加服务器的负载，从而验证服务器的性能变化曲线，找到拐点，从而才能分析性能采集的数据，进行性能优化。

稳定性测试

定义：在cpu不超过60%，内存也不超过60%的情况下，进行性能测试

目的：验证服务器在稳定运行时，会不会出现性能问题

稳定测试需要在服务器稳定运行的状况下来产生未来需要的数据量，来验证服务器产生未来的数据量后，会不会产生的问题

稳定性测试的时间：一般一天，七天，少部分项目，甚至一个月

压力测试

定义：压力测试和稳定性测试、负载测试是相似的概念。主要区别是，要模拟服务器在高压力的情况下的响应数据，处理请求的能力。

目的：验证服务器在高压下会不会崩溃

并发测试

定义：并发测试的测试方法和负载测试，压力测试，稳定性测试也有重合的地方，因为他们都是并发测试。主要区别是，并发测试的目的，是为了验证服务器在高并发下的处理性能。

并发测试关注高并发情况下，服务器的处理性能，和之前的要测试，负载测试，稳定测试的根本区别是，一个是直接模拟并发请求，另外一个是通过模拟模拟用户数，发送并发请求。并发请求，每个请求只发一次

模拟100个接口请求和模拟100个用户的区别

100个接口请求是指：同时发了100个请求

100个用户是指：开启了100个形成（相当于开启了100个while循环），这100个循环发送请求的频率，是由服务器的响应时间决定

100个用户向服务器发送请求时，假设服务器响应速度是0.1秒，那么100个用户，1秒可以发1000个并发请求

100个用户向服务器发送请求时，假设服务器响应速度是1秒，那么100个用户，1秒可以发100个并发请求

100个用户向服务器发送请求时，假设服务器响应速度是5秒，那么100个用户，1秒可以发20个并发请求

容量测试

定义：主要是对服务器的能够容纳的用户数，连接数等容量数据指标进行测试

例如：服务器能够支撑10000个用户在线活跃，那么我们需要，模拟10000个用户在线验证是否支持10000个用户，或者如果不知道最大用户数是多少，那么不断增加用户数，来查看最大的用户数容量

性能测试指标

常见的性能测试指标

1、响应时间

2.吞吐量（TPS，网络吞吐量，磁盘吞吐量）

吞吐量如果用于描述服务器处理请求能力时，叫做TPS；如果用户描述网络流量时，叫网络吞吐量；用于描述磁盘流量（读/写），叫做磁盘吞吐量（IOPS）

3、服务器资源使用率

4、错误率

5、运营指标（PV，UV）

6、并发数

响应时间

定义：指客户端发送请求，处理内部处理后，并把数据返回给客户端，一直到客户端接受到响应数据的时间

可以从两个维度来理解

• client：客户端发起请求，通过网络传输到服务端，服务端按照逻辑处理完成，并返回response给到客户端。
• server：从接受到请求开始处理，到完成逻辑处理并从服务端发出，到此结束，一个统计区间完成。

吞吐量

TPS：服务器处理事务的能力

接口请求就是一个事务，所以TPS就是描述服务器在单位时间内，处理请求数据的能力。

如果启动1个用户连续发送请求时，是发送事务请求，只有当服务器返回响应数据之后，客户端接收到之后，才会发送下一个请求。

单用户发送请求，服务器1秒处理完成，那么TPS是 1 请求数/秒

单用户发送请求，服务器0.1秒处理完成，那么TPS是 10 请求数/秒

10用户发送请求，服务器0.1秒处理完成，那么TPS是 100 请求数/秒

网络：网络吞吐量

是指，服务器的网速（上行/下行）

上行：上传到服务器的速度

下行：从服务器下载的速度。

一般查询服务器，下性比较高；写入数据的服务器，上行比较高。

磁盘IO：磁盘的吞吐量（IOPS）

是指，服务器在磁盘上写入和读取数据的能力。(既有读取和写入的次数瓶颈，也有读取和写入数据量的

瓶颈，所以才会分大量小文件传输和大文件传输)

服务器资源使用率

定义：是指系统各种资源的使用情况，一般用“资源的使用量/总的资源可用量×100%”形成资源利用率的数据

一台服务器主要由CPU，硬盘，内存，网络，虚拟资源组成 
建议cup不高于80% 
内存不高于80% 
磁盘不高于90% 
网络不高于80%

CPU

硬盘

内存：指内存的容量使用率

网络

交换内存

TPS连接数

错误率

错误率指系统在负载的情况下，失败交易概率

主要是用来描述服务器处理接口请求时，产生错误的请求

错误率=错误请求数/总请求数

注意：如果产生的错误是服务器内部的逻辑错误导致的，那么一定要修复

运营指标

PV：Page View 页面浏览数。就是指用户访问每个页面的次数

UV：Unique View 唯一访问量（用户访问量:用户的IP地址，用户的名，用户的唯一标识符）

在性能测试中，性能分析人员，需要根据PV和UV，来统计用户活跃情况和用户访问页面的情况，在根据这些数据，得出测试环境所需要的目标TPS是多少。也就是计算需求TPS的过程。

例如：线上活跃用户数是50万，那么测试环境的TPS应该达到多少才能满足生产的需要呢？

并发数

服务器每秒最大能并发处理的请求数量，就是并发数。这是衡量系统面临多大压力的一个重要指标。

并发数：一般是指并发请求数。

但是有的公司，也有描述为并发用户数。（尤其是使用Jmeter时）

Jmeter中，线程数就是用户数，而测试并发数时，我们使用Jmeter的集合点来集合线程进行请求测试，

那么所以有的人就会把并发数称之为并发用户数。

Jmeter的集合点，只会发送1个请求。

总结

• 真正的并发是服务端单位时间内接受并处理的请求数，并不是工具模拟的并发线程数。
• 其他条件不变的情况下，要提高TPS降低响应时间，最简单的办法是升配+扩容+缓存。
• 高并发/高性能/高可用其实是指用更少的时间处理更多请求，且服务长期提供服务。

性能测试流程

性能测试的流程

性能测试需求分析

性能测试计划及方案

性能测试用例

建立测试环境

测试脚本编写/录制

执行测试脚本

性能测试监控

性能分析和调优

性能测试报告总结

提示：使用不同的性能测试工具时，主要流程是不变的

性能需求分析

说明：性能需求分析是整个性能测试工作开展的基础，性能需求分析做的好不好直接影响到性能测试的结果

性能需求分析的目标明确被测系统，测试内容，测试策略，测试指标

1、熟悉被测系统

熟悉被测系统的业务功能，技术架构，明确性能测试内容

2、从业务角度明确测试内容

确定关键业务。即：用户使用频率较高的业务功能，从技术角度明确测试内容

例如：通常逻辑复杂度较高的业务也是CPU密集运算较大的地方，考量服务器CPU在预定性你那个指标下是否达标

3、明确性能测试策略

负载测试

稳定性测试

并发测试

4、明确性能测试的指标

如果没有明确需求指标，就通过查找想管资料，和类似的系统对比，以及对未来流量的预估，确定性能测试需求的指标

如果有明确需求指标，例如，类似如下指标

下订单业务并发20个用户

平均响应时间要小于等于3s

事务成功率为100%

CPU使用率小于等于85%

只需要根据执行分析结果与预期指标做对比，如果有不满足的，就需要分析问题所在

性能测试计划

项目概述（背景，目的）

测试范围

时间和人力的安排

测试策略

风险控制

测试约束

测试总结和报告

编写性能测试用例

要先知道性能测试用例接口模板的内容

搭建性能测试环境

在进行性能则试之前，需要先完成性能测试环境的搭建工作，测试环境一般包括硬件环境、软件环境及网络环境

如何搭建满足需求的性能测试环境（需要考虑的点）

• 集群均匀分布在不同可用区；

• 网关应用的单机配置（比如8C16G）；

• 虚拟机型保持一致（内核版本、计算型/IO型）；

• 需要绑定专门的域名，SLB和带宽需要大于预期的指标；

• 压测工具需要尽可能的支撑更高的并发流量发起（比如Wrk）；

• 因为涉及到鉴权和身份验证，需要提前预热相关的auth、token数据到缓存；

测试脚本的编写和录制

• 性能测试用例编写完成后，接下来就需要结合用例的需要，进行测试脚本的编写工作
• 录制或编写，根据不同的工具要注意代码冗余准备进行性能监控

准备进行性能监控

性能监控就是监控服务器的各项性能指标。例如：监控CPU、内存、网络、TPS、磁盘IO等

常见的性能监控工具

• 实时监控工具：用Jmeter自带的插件即可

• 离线监控：nmon监控Linux服务器的资源-

• Mysql：mysql自带的配置就有监控功能。

• Java的JVM监控，java工具自带监控工具：jvisualvm

性能分析和性能调优

• 性能测试分析人员经过对结果的分析以后，有可能提出系统存在性能瓶颈

• 验证-性能测试人员继续进行第二轮、第三轮……的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升。

• 系统调优由易到难的先后顺序如下：

  硬件问题 
  网络问题 
  应用服务器、数据库等配置问题 
  源代码、数据库脚本问题 
  系统构架问题
  

  在执行性能测试后，我们可以收集到性能测试的数据，并绘制成图表，根据图表，我们就可以得出性能的状态。可以根据性能需求指标，对比得到的性能指标，如果不满足性能需求，那么证明有瓶颈。

  需要进行优化。

  优化的方向可以参考以下7个点

  1、硬件（最直观，靠钱就能解决）

  2、架构优化：架构师进行优化

  3、代码优化

  4、数据库优化

  5、中间件优化（apache，apache tomcat，nginx，redis，rabbitmq等）

  6、算法优化（算法就是开发写的代码，用代码实现的数学逻辑，一般比较少）

  7、操作系统优化

  性能测试报告和总结

  性能测试报告的元素

  

常见的性能问题与原因

网络带宽

网络对性能的影响不言而喻。

如果带宽不足，单位时间内的请求过多，就会导致数据包的传输延迟较大。

负载均衡

现在的SLB层已经优化的足够好，但如果负载均衡出现问题，可能会导致流量分发不均匀，导致部分应用节点流量异常，健康检查不通过从而被踢下线。甚至服务注册重试失败或者弹性扩容不够及时，还会导致可用的节点承受了较多的请求最终导致雪崩效应。

安全策略

现在的软件系统，常见的安全防护策略有ddos高防以及WAF，一般都是部署在SLB和流量网关之间或者更上层。

安全防护策略常见的场景有异常检测、输入验证、安全补丁、状态管理以及基于规则和异常的保护功能。

流量网关

上面提到的几个部分都可以看做是互联网时代的基础通用层，而网关是伴随着微服务和容器化出现的，作为用户流量的系统入口，网关也承担了较多的功能，比如：

• 日志
• 身份鉴权
• 灰度发布
• 限流熔断
• 可观测性metrics
• 应用限流apm tracing

上述的功能，无论是身份鉴权还是可观测性的metrics的实现，都需要耗费一定时间。

特别是对于请求的RT比较敏感的业务，对流量网关功能的耗时要求更为严格。

web应用层

APP应用层

App应用层（即我们常说的后端服务）则更多的负责逻辑计算。逻辑计算是很吃资源的，当然和它的一些参数配置以及技术架构也有较大关联。常见的影响后端服务性能的因素如下：

• 硬件资源：如CPU/Memory；
• 参数配置：如Activethreads/TimeOut；
• 缓存配置：缓存中的大Key及缓存命中率；
• 并行计算：请求下游依赖是串行还是并行？
• 代码逻辑：最经典的例子——for循环无线套娃；
• 日志处理：特别是异常日志的处理以及生产日志级别；
• 处理机制：同步还是异步？如果是异步，MQ容量及消费能力如何？

数据存储层

数据存储层即数据库，数据库层面影响性能的因素应该是最常见也是最多的。比如：

• 锁：不合理的锁使用导致的请求等待；
• 索引：未加索引或索引未生效导致慢SQL；
• 数据量：表数据量过大导致的读写变慢等问题；

针对业务扩张及数据量变大问题，常见的优化策略有分库分表、垂直拆分、读写分离。