性能测试规范

目录

1.概述

1.1什么时候需要进行性能测试/压力测试

2.性能测试衡量指标

3.性能测试基本流程

3.1需求分析

3.2测试计划

3.3测试方案

3.4测试环境

3.5测试数据

3.6测试工具

3.7 测试脚本

3.8测试场景

3.9测试报告

3.10性能调优

4.测试执行策略

5.测试结果分析

5.1分析评估

5.2常用Linux监控命令


1.概述

1.1什么时候需要进行性能测试/压力测试

  1. 项目需求中对系统/应用的性能有明确要求
  2. 部分系统/应用上线后的某些常用业务,可能会出现大并发量操作的业务;
  3. 测试过程中响应时间已经超过可承受范围的业务;

2.性能测试衡量指标

  1. 响应时间:完成一次操作的时间。
  2. 最大并发量:最大支持的在同一时刻与服务器进行交互的在线用户数量。
  3. 请求成功率:结合压测工具断言,所有请求中成功接受响应所占比例。
  4. TPS:每秒事务数,指系统每秒能够处理的事务数量(一个事务可能是有多个请求组成)。
  5. 服务器资源利用率:性能测试工程中监控服务器的资源消耗情况,方便对性能结果进行分析、发现性能瓶颈;

3.性能测试基本流程

3.1需求分析

判断性能需测、免测及目标指标

3.2测试计划

测试目的、时间、负责人等。

3.3测试方案

项目背景、目的、测试目标、指标、被测范围、执行&监控策略等。

3.4测试环境

一般使用专用性能环境,环境配置与压测结果息息相关;

  1. 明确测试环境与生产环境的差异
  2. 网络环境稳定,压力机跟被测服务主机尽可能再同一局域网,避免网络环境导致压测结果不准确。

3.5测试数据

主要分为基础数据(铺底数据,不同铺底数据量情况下的压测结果往往也会有所差异)与测试数据(脚本参数化数据)。

3.6测试工具

根据需要选择所需的性能测试工具

  • 性能压试工具:JMETER,必要时进行分布式压测
  • 监控工具:Nmon、Linux 监控命令
  • 分析工具:Linux分析命令

3.7 测试脚本

根据测试计划&方案按需编写调试。

3.8测试场景

基准、单负载、混合、稳定性等,根据项目需要选择一种或多种;

3.9测试报告

压测结果分析&总结。

3.10性能调优

参考5.2“分析评估”。

4.测试执行策略

目的

测试方法

备注

基准测试

在服务器没有压力的情况下,获取单支交易的处理时间,为后续场景提供依据。

在系统无压力情况下单用户执行1分钟或重复100次,取平均响应时间。一般情况下不需要监控资源消耗、数据库处理等

单接口性能摸底,检查业务本身是否存在性能缺陷

单交易负载测试

获取系统单交易的最大处理能力,以及几个性能指标之间的关联关系、变化趋势,验证单个交易是否存在并发性问题。

使用压测工具逐步增加该交易并发用户数,每次执行10分钟,观察处理能力拐点,需监控服务器资源消耗、数据库处理能力等。

定位排查单接口瓶颈,是否支持并发,是否存在性能隐患

混合测试

考察各交易按配比逐渐加压的情况下,系统随负载变化处理能力趋势,如响应时间、TPS、资源消耗等,极限情况下系统处理能力

通过逐渐加压的方式,每次执行10~30分钟,需监控服务器资源消耗、数据库处理能力等。混合负载测试也需要判断拐点,判断方式与单交易负载测试相同,需注意各交易满足配比。

为验证需求提出的性能要求,结合实际可能的高压力场景,较全面的检测系统的性能表现

稳定性测试

系统长时间正常负载下的处理能力,是否有进程内存泄露、存储空间不足、inode数量不足、session未自动关闭、存量数据增长导致数据库执行计划不适用等隐藏问题。

对被测系统在混合场景拐点并发*75%压力下,执行2小时+,验证被测系统能否稳定运行。

执行时长建议:8小时(也可以是4、6、12、24、24*7等,根据实际情况灵活掌握)

5.测试结果分析

5.1分析评估

  1.  基准(主分析响应时间) ——参考依据
  2. 排队拐点(与基准对比响应时间) ——工作的线程超过CPU核数后很可能就会出现排队,如如CPU使用率>70%、systemload>系统CPU核数
  3. 最优并发拐点——当TPS不再明显上升时,响应耗时成倍增长前
  4. TPS拐点(最大处理能力,不断加压至TPS缓慢或不再上升趋势时)
  5. 错误拐点(逐步加压验)),这里就相当于一个告警值了,这里的报错需要从维度看,大部分可以分析接受(或优化 或熔断 或限流 或降级 或者前端友好提示),如一般建议  错误率<=0.1%;
  6. 在明确响应时间要求限制下,压力测试过程中,找到最大吞吐量(TPS)的拐点,结合被测服务&DB的资源(CPU、内存等)使用率,若使用率过低,继续增加并发用户数,若被测服务任意节点资源都未达到80%使用率,说明系统存在系统类,软件类问题和瓶颈,需要进一步分析并调优。

5.2常用Linux监控命令

工具(命令)

说明

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

整体概览

你可能感兴趣的:(服务器,性能测试规范,压力测试)