性能测试过程中，要关注哪些数据-CSDN博客

在性能测试中，需从用户体验、系统表现、资源消耗、稳定性四个核心维度监控和分析数据，确保覆盖 “端到端” 的全链路性能表现。以下是需重点关注的具体数据分类及说明：

核心业务指标直接反映用户实际操作的性能体验，是性能测试的首要评估标准，需优先监控高频、核心场景（如登录、下单、支付、搜索等）。

指标名称	定义	关键关注点	示例（参考阈值）
响应时间（Response Time）	从用户发起请求到接收完整响应的总时间（含网络传输 + 服务器处理 + 数据返回）	需拆分 “前端加载时间” 和 “后端接口响应时间”，定位慢瓶颈在哪一环	核心接口：<200ms（优秀），<500ms（合格）；页面加载：<2s（优秀），<3s（合格）
并发用户数（Concurrent Users）	同一时间段内操作系统的真实用户数（区别于 “虚拟用户数”）	需结合业务峰值（如秒杀、大促）设计并发量，观察系统是否出现卡顿、超时	电商大促：支持 10 万 + 并发用户；企业系统：支持 5000 + 并发用户
吞吐量（Throughput）	单位时间内系统处理的请求数量（通常以 “TPS”“QPS” 衡量）	TPS/QPS 需匹配业务峰值需求，同时关注 “吞吐量是否随并发增加而线性增长”	支付接口：>1000 TPS；搜索接口：>5000 QPS
成功率（Success Rate）	成功完成的请求数占总请求数的比例	需重点关注 “高并发下成功率是否下降”，失败需定位是 “超时”“报错” 还是 “数据不一致”	核心业务：100%（必须）；非核心业务：≥99.9%
业务完成量	单位时间内完成的核心业务交易数（如 “每小时下单量”“每日支付笔数”）	直接对应业务价值，需验证系统能否支撑目标业务规模	大促目标：每小时完成 5 万笔订单

服务器是业务处理的核心，需监控应用服务器、数据库服务器、中间件服务器等各类节点的资源消耗，判断是否存在资源瓶颈。

指标类别	具体指标	关键关注点	参考阈值（Linux 系统）
CPU 使用率	总 CPU 使用率、单核 CPU 使用率	避免 “单核跑满、多核空闲”（负载不均衡）；持续 > 80% 可能导致响应变慢	平均 < 70%，峰值 < 85%
内存使用率	已用内存、空闲内存、Swap 使用率	Swap 使用率过高（>20%）意味着物理内存不足，会触发磁盘交换，性能骤降	物理内存使用率 < 80%，Swap 使用率 < 10%
磁盘 I/O	磁盘读写吞吐量（IOPS）、读写延迟、磁盘使用率	随机读写延迟过高（>20ms）可能是磁盘瓶颈（如机械硬盘换 SSD）	读写延迟 < 10ms，磁盘使用率 < 85%
网络 I/O	网卡吞吐量（发送 / 接收速率）、网络延迟、丢包率	需对比网卡带宽上限（如 10G 网卡），丢包率过高会导致请求重试	吞吐量 < 带宽的 70%，丢包率 < 0.1%，延迟 < 5ms
进程 / 线程状态	活跃线程数、阻塞线程数、线程池队列长度	线程池队列满（如超过队列容量）会导致新请求被拒绝；阻塞线程过多可能是锁竞争或资源等待	活跃线程数≈CPU 核心数 ×2（参考），队列长度 < 阈值（如 200）

数据库是性能瓶颈的 “重灾区”，需重点监控查询效率、连接数、锁竞争等。

前端性能直接影响用户直观体验，尤其对于 Web/APP 应用，需结合浏览器 / 客户端工具（如 Chrome DevTools、Lighthouse）监控。

页面加载指标
- 首次内容绘制（FCP）：页面首次显示内容的时间（<1.8s 合格）。
- 最大内容绘制（LCP）：页面最大元素加载完成的时间（<2.5s 合格）。
- 首次输入延迟（FID）：用户首次交互（如点击按钮）到系统响应的时间（<100ms 合格）。
- 累积布局偏移（CLS）：页面元素意外偏移的程度（<0.1 合格，避免用户误触）。
资源加载指标
- 静态资源（JS、CSS、图片）加载时间、下载大小（需优化压缩，避免过大）。
- 接口请求瀑布图：观察是否存在 “串行请求阻塞”（可通过并行请求、懒加载优化）。
客户端状态
- APP 端：CPU 使用率、内存占用（避免内存泄漏导致崩溃）、帧率（如视频播放≥30fps）。

性能测试不仅要验证 “峰值性能”，还要确保系统在长时间运行下的稳定性（如 7×24 小时压测）。

长时间运行指标
- 性能衰减：观察响应时间、吞吐量是否随运行时间增加而恶化（如内存泄漏导致响应变慢）。
- 资源泄漏：CPU / 内存使用率是否持续上升且不回落（如未释放的线程、未回收的对象）。
异常指标
- 错误率：HTTP 错误（4xx/5xx）、业务错误（如 “订单创建失败”）的数量及占比。
- 超时率：请求因超时而失败的比例（需区分 “客户端超时”“服务器超时”）。
- 日志异常：系统日志中的警告（WARN）、错误（ERROR）信息（如空指针、数据库连接超时）。
容错与恢复指标
- 故障转移：模拟单台服务器宕机，观察集群是否自动切换（如 Redis 主从切换、Nginx 负载均衡容错）。
- 恢复时间（RTO）：故障后系统恢复正常的时间（如 < 5 分钟）。

全链路追踪：通过 APM 工具（如 SkyWalking、Pinpoint）将用户请求从 “前端→网关→应用→数据库→中间件” 串联，定位瓶颈节点（而非孤立看某一指标）。
对比基准：测试前定义 “基准值”（如正常负载下的响应时间、资源使用率），测试后对比 “峰值负载”“长期运行” 下的数据变化。
关联分析：例如 “响应时间变长” 时，需同时看 “CPU 使用率是否升高”“是否有慢 SQL”“网络是否丢包”，避免单一指标误判。
业务优先：所有技术指标最终需服务于 “业务可用性”—— 即使服务器资源使用率低，若核心业务成功率不足 100%，测试仍未通过。