- 前言
- 一、不同角色
- 1.开发
- 算法设计
- 架构设计
- 性能实践
- 数据库
- 软件性能的可测试性包括
- 2.测试
- 性能工程师一般需要具备的技能：
- 二、性能指标
- 并发用户数
- 响应时间
- 系统吞吐量
- 并发用户数、响应时间、系统吞吐量之间的关系
一、不同角色 1.开发 算法设计
算法设计包括：
- 核心算法的设计与实现是否高效
- 是否存在潜在的内存泄漏
- 是否存在并发环境下的线程安全问题
- 是否存在不合理的线程同步方式
- 是否存在不合理的资源竞争
架构设计包括：
- 系统整体是否可以方便的进行容量和性能扩展
- 应用集群的可扩展性是否经过测试和验证
- 缓存集群的可扩展性是否经过测试和验证
- 数据库的可扩展性是否经过测试和验证
性能实践包括：
- 代码实现是否遵守开发语言的性能实践
- 关键代码是否在白盒级别进行性能测试
- 是否考虑前端性能测试
- 必要的时候是否压缩数据
- 对于既要压缩又要加密的场景，是否采用先压缩后加密的顺序
数据库：
- 数据库表设计是否高效
- 是否引入索引
- sql语句的执行计划是否合理
- 数据库是否采用读写分离机制
- 系统冷启动后，当缓存大量不命中的时候，数据库承载的压力是否超负荷
软件性能的可测试性包括：
- 是否为性能分析器提供必要的接口支持
- 是否支持高并发场景下的性能打点
- 是否支持全链路的性能分析
- 性能需求的总结和抽象能力
- 根据性能测试目标，精准的性能测试场景设计和计算能力
- 性能测试场景和性能测试脚本的开发和执行
- 性能测试报告的分析解读能力
- 性能瓶颈的快速排查和定位能力
- 性能测试数据库的设计和实现能力
系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是5000个，那么这个数量，就是系统用户数。
同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间
响应时间：对请求作出响应所需要的时间
网络传输时间：N1+N2+N3+N4
应用服务器处理时间：A1+A3
数据库服务器处理时间：A2
响应时间=N1+N2+N3+N4+A1+A3+A2
系统吞吐量指单位时间内系统处理用户的请求数
从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量
从网络角度看，吞吐量可以用：字节/秒来衡量
对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。
当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R
其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数
阶段一：
当系统并发用户数较少时，系统的吞吐量也低，系统处于空闲状态，我们往往吧这个阶段称为“空闲区间”
阶段二：
当系统的负载不是很大时，随着系统并发用户数的增长，系统的吞吐量也会线性增长，我们往往把这个阶段称为“线性增长区”
阶段三：
随着系统并发用户数的进一步增长，系统的处理能力逐渐趋于饱和，因此每个用户的响应时长会逐渐变长。相应的，系统的整体吞吐量并不会随着用户并发数的增长而继续线性增长。我们往往把这个时间点称为拐点
阶段四：
随着雄通过并发用户数的增长，系统处理能力达到过饱和状态。如果继续增加并发用户数，最终所有用户的响应时间会变得无限长。相应地，系统的整体吞吐量会降为0，系统处于被压垮状态。我们称这个为“过饱和区间”
