性能测试基础概念
不同人眼中的性能测试
-
终端用户
业务操作的响应时间：系统响应时间（系统处理时间，数据库处理时间，网络传输时间）+ 前端展现时间（页面渲染时间） -
运维人员
基本和终端用户站在一个角度，希望响应速度快。但是，有时候角度相反。 比如： 系统配置方案A可以满足100万用户并发访问，响应时间是3s； 系统配置方案B可以满足500万用户并发访问，响应时间是8s; 从利益最大化角度，可能就会选择B方案。 -
开发人员
关注的性能相关的设计和细节，涵盖软件开发的全过程。 比如： 算法设计（是否采用缓冲机制，并发环境的线程安全，不合理的资源竞争等） 架构设计（是否方便扩容等） 数据库（表设计是否高效，索引是否合理，sql是否高效，是否需要读写分离机制） ... -
性能测试人员
需求总结和抽象能力，设计精准的性能测试场景。 报告分析解读能力，快速排查和定位性能瓶颈。 性能测试数据的设计和实现能力。 ...
性能测试中常用的3个指标
并发用户数
- 业务层面的并发用户数（实际系统的用户总数）
- 服务器层面的并发用户数（同时向服务器发生请求的数量）
举例：
系统A用5000个用户，但是根据日志分析，同时在线的用户峰值时2500人。
某一时刻，2500个用户30%在浏览网页（没有发起请求），20%在填写订单（没有发起请求），5%在提交订单，15%在查询商品，余下30%没有任何操作。
这个时候对服务器产生压力的只有500个用户，即：（5%+15%）*2500=500。
因此，分析得到准确的用户行为模式，是性能测试中的关键一环。
获取用户行为模式主要分两种：
- 已上线的系统：通过日志分析用户行为，以及峰值并发量等信息
- 未上线的系统：参考行业中类似系统的统计信息来建立用户模型
响应时间
响应时间包含前端时间（渲染，页面资源加载），后端时间（网络时间，系统处理时间，数据库处理时间），一般响应时间指的是后端响应时间。
系统吞吐量
系统吞吐量是最能直接体现系统负载能力的指标，吞吐量的计算必须以“单位时间”为前提。
对性能测试而言：通常用每秒的请求数，每秒的页面数，每秒的字节数来衡量
对业务角度而言：单位时间的业务处理数量
单一一个系统吞吐量指标，是不能反应软件性能的，需根据实际情况结合并发用户数，响应时间来评估。
比如：
场景1：100个用户，每隔1s发一个请求
场景2：1000个用户，每隔10s发一个请求
这两个场景都有相同的吞吐量（100/s，每秒100个请求），但是系统性能拐点肯定不同，因为两个场景所占用的系统资源是不同的。
并发用户数，响应时间，系统吞吐量之间的关系
- 当并发用户数较少时，系统吞吐量也低，系统处于空闲状态。该阶段称为
空闲区间。 - 系统整体负载不是很大时，随着系统并发用户数的增长，系统吞吐量也会线性增长。该阶段称为
线性增长区间。 - 随着系统并发用户数进一步增长，系统的处理能力趋于饱和，此时每个用户的响应时间会渐渐变长，不再呈线性增长，此时称为
拐点。 - 更糟糕的是，随着用户数的增长，系统处理能力达到过饱和状态，最终所有用户的响应时间会变得无限长，此时系统的吞吐量会降为0。该阶段称为
过饱和区。
对于后端性能测试的负载，一般会把它设计在线性增长区间，对于压力测试的负载，会将它设计在系统的拐点上，甚至过饱和区。
