1 前言
性能是一个充满挑战的领域，它是主观的，复杂的。
主观在于对系统是否存在性能问题的判断是模糊的，用户认为系统的好与坏也没有界定。故我们需要通过定义清晰的目标，如响应耗时、响应延时范围等等指标，把主观的性能变得客观。
复杂在于往往出现性能问题，没有一个明确的分析起点，通常是根据经验从猜测开始，比如，网络、系统间调用连锁故障。解决复杂的性能问题通常需要全局性的方法。整个系统（包括自身内部和外部的交互度可能需要被排查研究），涉及到的技能非常广泛。
2 概述
2.1 目的
为系统、项目在性能测试时，遵循相同标准，统一原则。本文主要对性能指标概念及分析方法、评判标准、测试策略以及工具使用进行说明。旨在指导测试人员更好的理解各个性能指标，对系统的性能质量做出准确的评价与分析。
2.2 适用范围
本规范适用于测试、开发、运维等任何想了解性能测试活动人群。
3 性能测试指标
3.1 系统指标
3.1.1 定义
响应时间：完成一次操作的时间。包括用于等待和服务的时间，也包括用来返回结果的时间。
TPS：每秒事务数，指系统每秒能够处理的事务数量（一个事务可能是有多个请求组成）。
QPS：每秒查询率，指系统每秒能够处理的查询（常指一个request请求）数量。
并发用户数：在同一时刻与服务器进行交互的在线用户数量。
请求成功率：结合压测工具断言，所有请求中成功接受响应所占比例。
3.1.2 获取方法
前提：网络环境稳定，压力机跟被测服务主机尽可能再同一局域网，避免网络环境导致压测结果不准确。
一般性能压测工具均会有并发用户数、响应耗时、TPS、错误率等结果统计。具体压测方法参考本文档第六章节“性能测试执行策略”。
3.1.3 分析方法
结合不同压力情况的的压测类型&目的综合分析。
拐点补充说明：
1) 基准（主分析响应时间） ——参考依据
2) 排队拐点（与基准对比响应时间） ——工作的线程超过CPU核数后很可能就会出现排队
3) 最优并发拐点——当TPS不再明显上升时，响应耗时成倍增长前
4) TPS拐点（最大处理能力，不断加压至TPS缓慢或不再上升趋势时）
5) 错误拐点（逐步加压验)），这里就相当于一个告警值了，这里的报错需要从维度看，大部分可以分析接受（或优化 或熔断 或限流 或降级 或者前端友好提示）
错误出现在TPS拐点前或者资源瓶颈前，需要关注
3.2 资源指标
3.2.1 定义
CPU：CPU使用率——非空闲时间占总CPU时间的百分比；平均负载——系统的平均活跃进程数。
内存：内存使用率——已经使用的物理内存占总物理内存的百分比；YGC/FGC——垃圾回收，YGC 是对新生代堆进行回收，FGC是对整个堆内存进行回收；关注YGC/FGC执行次数及耗时。
磁盘I/O：磁盘I/O使用率——磁盘忙于处理I/O请求的百分比（%util）。I/O响应时间：I/O请求从发出到收到响应的间隔时间（r_await+w_await）。
网络：带宽——链路的最大传输速率；吞吐量——压测时实际的数据传输速率。
3.2.2 获取方法
在压测时同步监控各被测服务资源使用情况，可根据公司集成的监控平台进行查看监控分析
应用：
现市场上有很多开源资源监控平台（如grafana），如使用的是云产品可以在对应云平台查看对应主机资源使用情况，也可登录到主机使用Linux性能分析相关命令查看各指标使用情况。
Linux观测CPU命令：uptime、vmstat、mpstat、sar、ps、top、pidstat、time和ptime、turbostat、showboost、pmcarch、perf~
Linux观测内存命令：vmstat、PSI、swapon、sar、slabtop、numastat、ps、top、pmap、perf、drsnoop、wss、bpftrace~
Linux观测磁盘命令：iostat、sar、PSI、pidstat、perf、biolatency、biosnoop、iotop、biotop、biostacks、blktrace、bpftrace~
Linux观测网络命令：ss、ip、ifconfig、nstat、netstat、sar、nicstat、ethtool、tcplife、tcptop、tcpdump、bpftrace、tcpretrans、Wireshark~
DB：
如裸金属部署结合Linux+SQl命令查看分析。现大部分公司数据库多直接用云产品，相对便捷清晰，如云产品可登录到云平台查看对应DB实例各指标情况，包括SQL的执行情况等等。
其他：
mongo、redis、ES等根据部署类型具体分析，如裸金属部署结合Linux+命令查看分析，如为云产品可在对应的云平台进行监控分析。
3.2.3 分析方法
通过“TPS”与“系统资源使用率”之间的关系进行分析。
通过并发用户数的增加和资源使用率的增长进行分析，判断并发资源开销。
数据库除各资源表现同时需关注SQL执行情况。
以下是根据经验给出的不同类型系统子下资源合理利用率，仅供参考、仅供参考、仅供参考~
以单实例2C机器为例
|
功能类型 |
接口维度 |
接口类型 |
基准90%RT |
TPS |
单实例默认配置 |
举例 |
|
查询类 |
端到端查询 |
简单 |
200ms |
200笔/秒 |
2C |
1、直接查询数据库或缓存 |
|
一般 |
200ms |
100笔/秒 |
2C |
1、查询后重组 |
||
|
复杂 |
400ms |
50笔/秒 |
2C |
1、查询后重组 |
||
|
子系统/子服务查询 |
简单 |
50ms |
400笔/秒 |
2C |
1、直接查询数据库或缓存 |
|
|
一般 |
100ms |
200笔/秒 |
2C |
1、涉及服务≥2（除网关、转发等无业务逻辑服务） |
||
|
复杂 |
200ms |
80笔/秒 |
2C |
1、涉及表≥5（除配置表） |
||
|
金融维护类 |
端到端 |
非核心维护 |
500ms |
50笔/秒 |
2C |
all |
|
核心/支付维护类 |
1000ms |
50笔/秒 |
8C |
all |
||
|
核心/支付交易类 |
1000ms |
50笔/秒 |
8C |
all |
||
|
子系统/子服务 |
非核心维护 |
150ms |
100笔/秒 |
2C |
all |
|
|
核心/支付维护类 |
500ms |
100笔/秒 |
8C |
all |
||
|
核心/支付交易类 |
500ms |
100笔/秒 |
8C |
all |
||
|
消费能力 |
mq/kafka~ |
|
|
150笔/秒 |
2C |
all |
3.3 其他
饱和度：某一资源无法提供服务的工作排队程度。
瓶颈：在系统性能里，瓶颈指的是限制系统性能的那个资源。分辨和移除系统瓶颈是提高系统性能的一项重要工作。
4 性能测试基本流程
1) 需求分析：判断性能需测免测及目标指标（众安当前判断在jira控制，指标按照所制定的统一指标），如有特殊情况特殊分析（如审计、特定活动）。
2) 测试计划：测试里程碑、目的、时间、负责人等。
3) 测试方案：背景、目的、指标、被测范围、执行&监控策略等。
4) 测试环境：一般使用专用性能环境，环境配置与压测结果息息相关，当前ZAGJ性能环境各服务配置基本为生产单实例等配。
5) 测试数据：主要分为基础数据（铺底数据，不同铺底数据量情况下的压测结果往往也会有所差异）与测试数据（脚本参数化数据）。
6) 测试脚本：根据测试计划&方案按需编写调试。
7) 测试场景：基准、单负载、混合、稳定性等。
8) 测试报告：压测结果分析&总结。
9) 性能调优：参考本文档第5章节“分析评估&调优”。
5 分析评估&调优
5.1 现象分析
在明确响应时间要求限制下，压力测试过程中，找到最大吞吐量（TPS）的拐点，结合被测服务&DB的资源（CPU、内存等）使用率，若使用率过低，继续增加并发用户数，若被测服务任意节点资源都未达到80%使用率，说明系统存在系统类，软件类问题和瓶颈，需要进一步分析并调优。
5.2 调优示例
|
层级 |
调优对象 |
|
应用程序 |
应用程序逻辑、请求队列大小、执行的数据库请求 |
|
数据库 |
数据库表的布局、索引、缓冲 |
|
系统调用 |
内存映射或读写、同步或异步I/O标志 |
|
文件系统 |
记录尺寸、缓存尺寸、文件系统可调参数、日志 |
|
存储 |
RAID级别、磁盘类型和数目、存储可调参数 |
5.3 何时停止分析
1) 当已经解决大部分性能问题时
2) 当潜在投资回报率低于分析成本时
3) 当其他地方有更大的投资回报率时
6 性能测试执行策略
|
类型 |
目的 |
测试方法 |
备注 |
|
基准测试 |
在服务器没有压力的情况下，获取单支交易的处理时间，为后续场景提供依据。 |
在系统无压力情况下单用户执行5分钟或重复2000次，取平均响应时间。一般情况下不需要监控资源消耗、数据库处理等 |
单接口性能摸底，检查业务本身是否存在性能缺陷 |
|
单交易负载测试 |
获取系统单支交易的最大处理能力，以及几个性能指标之间的关联关系、变化趋势，验证单个交易是否存在并发性问题。 |
使用压测工具逐步增加该交易并发用户数，每次执行10分钟，观察处理能力拐点，需监控服务器资源消耗、数据库处理能力等。 |
定位排查单接口瓶颈，是否支持并发，是否存在性能隐患 |
|
混合测试 |
考察各交易按配比逐渐加压的情况下，系统随负载变化处理能力趋势，如响应时间、TPS、资源消耗等，极限情况下系统处理能力 |
通过逐渐加压的方式，每次执行10~30分钟，需监控服务器资源消耗、数据库处理能力等。混合负载测试也需要判断拐点，判断方式与单交易负载测试相同，需注意各交易满足配比。 |
为验证需求提出的性能要求，结合实际可能的高压力场景，较全面的检测系统的性能表现 |
|
稳定性测试 |
系统长时间正常负载下的处理能力，是否有进程内存泄露、存储空间不足、inode数量不足、session未自动关闭、存量数据增长导致数据库执行计划不适用等隐藏问题。 |
对被测系统在混合场景拐点并发*75%压力下，执行2小时+，验证被测系统能否稳定运行。 |
执行时长建议：8小时（也可以是4、6、12、24、24*7等，根据实际情况灵活掌握） |
7 性能命名规范
S、C、R分别表示脚本、场景、结果
Base、single、mix、stable分别表示基准、单负载、混合、稳定性
7.1 脚本命名规范
【需求ID】S-yyMMddHHmm.jmx
必要时可添加场景名称
如下
|
基准 |
【需求ID】S-2212211148-base.jmx |
|
单场景 |
【需求ID】S-2212211148-single.jmx |
|
混合 |
【需求ID】S-2212211148-mix.jmx |
|
稳定性 |
【需求ID】S-2212211148-stable.jmx |
7.2 结果命名规范
【需求ID】R-场景-并发用户数-MMddHHmm.jtl
Eg：
|
【需求ID】R-base-02071530.jtl |
基准测试结果，因为基准默认为1并发，故无需添加并发用户数 |
|
【需求ID】R-single-50U-02071530.jtl |
单负载50并发结果 |
|
【需求ID】R-single-1_50U-02071530.jtl |
单负载1~50U阶梯并发结果 |
|
【需求ID】R-mix-1_200U-02071530.jtl |
混合1~50U阶梯并发结果 |
8 Linux性能分析60秒
|
# |
工具（命令） |
说明 |
|
1 |
uptime |
分别输出 1 分钟、5 分钟、15 分钟的平均负载情况 |
|
2 |
dmesg -T | tail |
查看最近 10 条系统消息（如果有）。查找可能导致性能问题的错误。上面的示例包括 oom-killer 和 TCP 丢弃请求。 |
|
3 |
vmatat 1 |
系统级统计：运行队列长度、交换、CPU总体使用情况 |
|
4 |
mpstat -P ALL 1 |
CPU平衡情况：如单个CPU很繁忙，意味着现成扩展性很糟糕 |
|
5 |
pidstat 1 |
每个进程CPU使用情况：识别意外的CPU消费者，以及每个进程的用户/系统CPU时间 |
|
6 |
iostat -sxz 1 |
磁盘I/O统计：IOPS和吞吐量、平均等待时间、忙碌百分比 |
|
7 |
free -m |
内存使用情况，包括文件系统的缓存 |
|
8 |
sar -n DEV 1 |
网络设备I/O，数据包、吞吐包等 |
|
9 |
sar -n TCP,ETCP 1 |
TCP统计：连接数、重传 |
|
10 |
top |
整体概览 |
标签：性能,系统,规范,并发,TPS,测试,CPU From： https://www.cnblogs.com/manlucky/p/17109916.html