摘要：
了解需求，明确目的，获取（线上）数据加以分析，制定指标
1.1 新上线项目
1、指标以目的为导向
1）容量验证——某软硬件条件下系统最大处理能力，为运维提供容量模型/预估 2）稳定性验证 3）有特定的预期指标（1~3年未来规划） 注：基准性能需提前把控（重点关注在无压力情况下的响应耗时）2、业务模型
1）参考历史项目或其他同行业项目
2）业务产品综合评估
注：待系统上线后可观察一段时间，按照较为标准的业务模型在验
1.2 已上线系统
- 根据历史数据分析获取方式 1）请运维同学协助查看；2）通过现有监控平台等途径获取
- 版本迭代（按照原预期）
1.3 性能需求指标
|
序号 |
指标类型 |
指标名称 |
指标要求 |
说明 |
|
1 |
系统指标 |
90%基准响应时间 |
≤200ms |
指无压力情况下从客户端发起业务请求到得到响应的整个过程所经历的时间 |
| 90%负载响应时间 | ≤1s | 指在TPS满足预期指标负载下从客户端发起业务请求到得到响应的整个过程所经历的时间 | ||
|
2 |
并发/在线用户数 |
XXX |
在同一时刻与服务器进行交互（指向服务器发出请求）的在线用户数 |
|
|
3 |
系统处理能力（TPS） |
XX笔/秒 |
每秒处理事务数（处理客户的请求数） |
|
|
4 |
查询类交易成功率 |
>=99.9% |
指交易成功的数量占发出的总交易量的百分比 |
|
|
支付类交易成功率 |
>=99.99% |
|||
|
5 |
服务资源指标 |
CPU |
<=90% |
CPU负载不得超过90%，生产正常超过60%会提示预警 |
|
6 |
内存 |
/ |
内存无泄漏，GC正常 |
|
|
7 |
磁盘I/O |
/ |
读写正常，无等待排队。 |
|
|
8 |
网络I/O |
/ |
数据传输上下行无阻塞异常 |
|
|
9 |
无慢查询 |
<100ms |
数据库SQL查询耗时 |
1.3.1 TPS折算方式：
- 常用的二八原则（80%的交易在20%时间内完成）；
- 根据并发用户数：TPS=并发用户数/响应时间 ——不是特别推荐，也没有特别正确的推理，因为并发用户数本身是一个比较争议的点
1.3.2 响应时间定义方式：
1、基准200ms,负载1s（在满足TPS指标的情况下所涉接口需≤1s/3s）
业界定义：1357原则，1s优秀，3s良好，5s及格，7s不合格。随着用户对“快”的要求越来越高，一般的请求超过3s就不能接受。
2、附响应时间过程图
1.3.3 用户数折算方式——不推荐
- 并发用户：同时对服务产生请求的用户总数
- 在线用户：所有正在访问系统用户(不一定作操作)
- 系统用户：系统额定的用户数量或者注册用户数
对于并发用户数的概念，很多时候都是模糊的，所谓官方推理或经验都不是很准确，这跟系统本身的属性有很大关系，以下几种折算方式仅供参考
- 在线人数：并发用户数峰值计算C^=C+3*根号C
1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C‘ = C + 3*根号C
C是平均并发用户数，C’是并发用户数峰值，n是login session的数量，L是login session的平均长度，T是值考察的时间长度。
2. 按照TPS进行计算：公式为 C = (Think time + 1)*TPS
并发用户数=TPS*响应时间
3. 二八原则：（用户总量/统计时间）*影响因子（一般为3）来进行估算并发量。
比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为50000*80%/（3*60*60）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！
4. 据系统用户数计算：
并发用户数 = 系统最大在线用户数的5%到12%
标签：响应,性能,系统,性能需求,指标,并发,TPS,测试,用户数 From： https://www.cnblogs.com/manlucky/p/16422494.html