性能测试方案

制定者 ：@孙秀芳
审核人 ：
创建时间：2024.01.15
文档状态：草稿、修订、发布、废弃
最后更新：2024.01.30

变更记录
版本号
修改日期
修改人
修改内容简述
v0.1
2024.01.15
孙秀芳
初始创建文档、初稿文档结构
v0.2
2024.01.16
孙秀芳
完善初稿文档
v0.3
2024.01.29
孙秀芳
新增指标监控工具/命令使用
v0.4
2024.01.30
孙秀芳
新增内容：dstat 监控数据的存储&测试范围要明确分阶段进行&性能测试的测试功能点&压力服务器在线安装JDK和jmeter

一、测试目标

1. 能力验证：
2. 确保接口响应时间满足业务需求。
3. 检测CPU、内存、磁盘、网络的使用情况。
4. 收集性能测试数据：
5. 了解当前系统的指标数据
6. 为后续调优工作提供参照数据
7. 性能调优：目标是优化响应时间，我们可能选取的策略是以空间换时间，以牺牲内存或扩大缓存为代价
8. 硬件环境的调整
9. 系统设置的调整

二、测试范围和计划

目前只针对商业化版本的重要且响应较慢的接口进行测试，后期持续补充其他接口及前端渲染时间，本方案仅适用于性能测试第一阶段测试任务，后续阶段任务会给出新方案或更新此方案。
1.检索留痕数据慢：
接口名称：留痕还原 获取互动人员
接口路径：POST /api/trace/v1/work/restore/related
性能指标：响应时间（具体数量级可接受时间待定）
测试环境：演示环境（compliance）
测试范围：单接口不同参数

接口名称：详细天维度数据查询
接口路径：POST /api/trace/v1/work/restore/day
性能指标：响应时间（具体数量级可接受时间待定）
测试环境：演示环境（compliance）
测试范围：单接口不同参数

接口名称：获取留痕聚合数据
接口路径：POST /api/trace/v1/work/restore/summary
性能指标：响应时间（具体数量级可接受时间待定）
测试环境：演示环境（compliance）
测试范围：单接口不同参数

接口名称：分页查询留痕内容（关注渲染时间）
接口路径：POST/api/trace/v1/work/restore/page
性能指标：响应时间（具体数量级可接受时间待定）
测试环境：演示环境（compliance）
测试范围：单接口不同参数

接口名称：沟通还原获取通讯录（关注渲染时间）
接口路径：POST/api/trace/v1/work/chat/contacts
性能指标：响应时间（具体数量级可接受时间待定）
测试环境：演示环境（compliance）
测试范围：单接口不同参数

2.导出留痕数据慢：
接口名称：全程留痕动态导出
接口路径：POST /api/trace/v1/work/restore/export
性能指标：响应时间（具体数量级可接受时间待定）
测试环境：演示环境（compliance）
测试范围：单接口不同参数

三、测试工具和技术

1.压力模拟工具：Jmeter
ApacheJMeter，是一个纯正的Java的开源软件。最初用于测试Web应用程序，后来扩展到其他测试功能。相比于其他性能测试工具，Jmeter既好用又开源。
2.性能监控工具：Nmon/监控命令
nmon是IBM公司开发的Linux性能监控工具，可以实时展示系统性能情况，也可以将监控数据写入文
件中，并使用nmon分析器做数据展示。
使用不同的监控命令分别监控CPU，内存的使用情况。

四、压力测试服务器

1. 操作系统：Linux
2. 安装和配置软件：压力测试工具（jmeter）
3. 架构和网络配置：根据您的需求和架构设计，设置网络配置，包括 IP 地址、端口号、域名、子网掩码等。
4. 运行时环境：根据您的应用程序需求，安装所需的运行时环境，例如 Java Runtime Environment。
5. 硬件需求： CPU、内存、磁盘
6. 监控和日志

五、压测脚本准备

1. 创建线程组（Thread Group）：在测试计划中添加线程组元素，配置并发用户数和循环执行次数。
2. 添加取样器（Sampler）：通过添加取样器元件HTTP Request，模拟用户发送请求。
3. 设置取样器请求参数和请求头：为每个请求设置相应的请求参数和请求头。
4. 添加断言（Assertion）：断言元件响应断言/JSON断言用于验证服务器响应的正确性。
5. 添加监听器（Listener）：监听器元件用于捕获和分析测试结果，可以选择适当的监听器，如聚合报告、查看结果树、图表等，以查看并分析性能指标。
6. 运行测试计划：保存并运行测试计划，JMeter将模拟用户行为，发送请求，并记录性能指标。
7. 分析和评估结果：使用监听器和报告生成的数据，分析测试结果，并评估性能指标，如响应时间、吞吐量、错误率等，以获得关于系统性能的洞察。

六、测试执行

a.压力机安装并配置好JDK、jmeter
（1）使用 apt 命令下载 JDK
sudo apt install openjdk-<18>-jdk
使用 wget 命令下载 Apache JMeter 的二进制发布版本
wget https://downloads.apache.org/jmeter/binaries/5.1.1.tar.gz
（2）解压：tar -xvf jdk-8u221-linux-x64.tar.gz
tar -xvf apache-jmeter-5.1.1.tar.gz
（3）修改配置文件：vi /etc/profile
（4）光标移动到最后一行，添加以下配置
JAVA_HOME=/usr/local/tools/jdk1.8.0_241
JMETER_HOME=/usr/local/tools/apache-jmeter-5.1.1
CLASSPATH=$:CLASSPATH:$JAVA_HOME/lib/
PATH=$PATH:$JAVA_HOME/bin:$JMETER_HOME/bin
export PATH JAVA_HOME CLASSPATH
（5）退出vi，执行命令source /etc/profile，让配置生效
（6）进到Jmeter 根目录下需要添加执行权限 chmod +x ./*
（7）执行java-version、jmeter -v命令，如果能看到版本信息，配置成功
b.本地调试好jmeter脚本后，上传至压力机（方案2:上传gitlab，gitlab下载）
c.单机器压测
jmeter -n -t bczs.jmx -l result.jtl
-n: 命令行模式启动jmeter，no-gui
-t：jmx脚本路径；
-l：jtl结果文件存放路径
d.获取html报表
（1）进入jmeter的bin目录下，修改reportgenerator.properties
（2）修改jmeter.reportgenerator.overall_granularity=1000（报表中数据展示间隔1秒）（根据压测时间自行修改）
（3）创建一个存放数据报表的文件夹 mkdir report
（4）执行命令：jmeter -g result.jtl -o ./report

七、指标监控

关注指标

• 响应时间（Response Time）：响应时间是指从发送请求到接收到完整响应的时间间隔。

• 吞吐量（Throughput）：吞吐量是指系统在单位时间内能处理的请求数量。

• 错误率（Error Rate）：错误率表示系统在处理请求过程中发生的错误数量与总请求数量之间的比例。
  [图片]

• 并发用户数（Concurrent Users）：并发用户数是指同时发送请求并与系统交互的用户数量。

• CPU 使用率（CPU Usage）：CPU 使用率表示系统在处理请求时所使用的 CPU 资源的百分比。
  命令：top
  [图片]
  保存执行top的监控数据
  创建一个空的文本文件，用于保存监控数据：
  touch monitoring_data.txt
  使用以下命令执行 top 命令并将输出数据追加写入到文件中：
  while true; do
  top -b -n 1 >> monitoring_data.txt
  sleep <5>
  done

  这个脚本会无限循环运行，每5秒执行一次dstat命令并将输出追加到dstat_output.txt文件中，压测结束后通过以下命令终止dstat
  查找 top 命令的进程 ID（PID）：ps -ef | grep top
  终止 top 命令的运行，将 替换为您在上一步中找到的进程 ID（PID）：pkill -P

• 内存使用率（Memory Usage）：内存使用率表示系统在处理请求时所使用的内存资源的百分比。
  命令：free -m
  [图片]

• 平稳性和稳定性（Stability）：进行长时间运行的测试，观察系统在稳定和持续负载下是否出现性能下降、内存泄漏或资源耗尽等稳定性问题。

dstat
dstat是一个全能监控工具，整合了CPU、内存、磁盘、网络等几乎所有的监控项，支持实时刷新
dstat需要先进行安装：yum install -y dstat
监控命令：dstat -tcmnd --disk-util
[图片]

保存执行dstat的监控数据
使用shell脚本每5秒保存一次数据到文件
#!/bin/bash

output_file=“dstat_output.txt”

while true; do
dstat -tcmnd --disk-util >> “$output_file”
sleep 5
done
将上述脚本保存为文件，例如dstat_save.sh，然后通过以下命令使脚本可执行并运行它：
chmod +x dstat_save.sh
./dstat_save.sh
这个脚本会无限循环运行，每5秒执行一次dstat命令并将输出追加到dstat_output.txt文件中，压测结束后通过以下命令终止dstat
查找 dstat 命令的进程 ID（PID）：ps -ef | grep dstat
终止 dstat 命令的运行，将 替换为您在上一步中找到的进程 ID（PID）：pkill -P

将输出数据追加写入到文件中：nohup dstat -tcmnd --disk-util > monitoring_data.txt &
nohup dstat 2 | tee -a dstat.log &
查找 dstat 命令的进程 ID（PID）：ps -ef | grep dstat
终止 dstat 命令的运行，将 替换为您在上一步中找到的进程 ID（PID）：：pkill -P

nmon
nmon是一种在AIX与各种Linux操作系统上广泛使用的监控与分析工具，它能在系统运行过程中实时地捕捉系统资源的使用情况，记录的信息比较全面，并且能输出结果到文件中，然后通过nmon_analyzer工具产生数据文件与图形化结果。
nmon通过命令行启动监控，捕获服务器的各项数据，命令如下：
./nmon_x86_64_centos6 -s 10 -c 60 -f -m /root/nmon
#参数说明
-f 监控结果以文件形式输出，默认机器名+日期.nmon格式
-F 指定输出的文件名，比如test.nmon
-s 每隔多少秒抽样一次，单位是秒，上述命令配置是10s；
-c 采样次数，上述命令配置是60，即监控总时长为10*60=600秒
-m 指定生成的文件目录
[图片]

报表模式：
命令：./nmon -ft -s 5 -c 1000
Nmon文件需要关注的标签页
1、cpu_all
2、diskbusy
3、net
4、mem
[图片]
下载文件用Excel分析器打开
[图片]
[图片]

六、调优回归

a、应用层面
（1)优化代码，代码问题往往会因为消耗系统资源而暴漏出来，例如代码导致内存溢出，使 JVM 内存用完，而发生频繁的 FullGC，导致 CPU 偏高。
（2)优化设计，主要是优化业务层和中间件层代码，例如可以采用代理模式，放在频繁调用的创建对象的场景里，共享一个创建对象，减少创建对象的消耗。
（3)优化算法，选择合适的算法降低时间复杂度。
b、数据库层面
（1)表结构与索引优化。
主要是对数据库设计、表结构设计以及索引设置维度进行的优化，设计表结构的时候，考虑数据库的水平与垂直的拓展能力，提前规划好将来数据量、读写量的增长，规划好分库分表方案。对字段选择合适的数据类型，优先选用较小的数据结构。
（2)SQL 语句优化。
主要是对 SQL 语句进行的优化，使用 explain 来查看执行计划，来查看是否使用了索引，使用了哪些索引。也可以使用 Profile 命令分析语句执行过程中各个分步的耗时。
（3)数据库参数优化。
主要是对 数据库服务的配置进行优化，例如连接数的管理，对索引缓存、查询缓存、排序缓存等各种缓存大小进行优化
c、硬件层面
对硬件设备和操作系统设置进行优化，例如调整操作系统参数、禁用 swap、增加内存、升级固态硬盘。
d、产品功能设计层面
可通过限制时间或过多检索对象的条件，尽量避免超大批量数据的查询。

七、测试报告

报告会在调优完成并达到业务需求后以文档格式给出，包含：
1、测试背景目标
2、测试工具及环境配置
3、测试指标
每个接口的tps和接口响应时间、成功率
4、测试内容
性能测试场景的设计、测了哪些接口(单接口和链路的接口)、每个接口测试出来的数据是多少比如：执行时间/min、并发、用户数/vuser、TPS、平均响应时间/ms、90%用户响应时间/ms、成功笔数 、失败笔数、成功率 load、CPU、内存。
5、测试结论
每个接口的tps，响应时间是否达标合格，是否满足上线要求
6、测试风险及遗留问题
风险、遗留问题、未测试场景
7、附件
缺陷清单、测试结果、优化建议

八、测试执行计划

• 环境准备（2天）
• 测试用例数据准备（1天）
  测试场景
  一个检索对象（留痕数据量前1检索对象）按人一次检索（沟通对象1个&时间段不选&关键词3个&留痕来源&留痕类型全选）

多个检索对象（留痕数据量前10检索对象）按人一次检索（沟通对象10个&时间段不选&关键词3个&留痕来源&留痕类型全选）

多个检索对象（留痕数据量前10检索对象）按人一次检索（沟通对象10个&时间段选择近一年&关键词5个&留痕来源&留痕类型全选）
多个检索对象（留痕数据量前10检索对象）按人一次检索（沟通对象10个&时间段选择近一年&关键词5个&留痕来源选择企微和通话记录和短信&留痕类型选择文本和音频和视频）
多个检索对象（留痕数据量前10检索对象）二次检索（关键词5个，时间空，留痕来源&留痕类型全选）
多个检索对象（留痕数据量前10检索对象）二次检索（关键词5个，时间选择近一年，留痕来源&留痕类型全选）
多个检索对象（留痕数据量前10检索对象）二次检索（关键词5个，时间选择近一年，留痕来源为企微和通话记录和短信，留痕类型为文本和音频和视频）
多个检索对象（留痕数据量前10检索对象）三次检索（关键词5个，时间空，留痕来源&留痕类型全选）
多个检索对象（留痕数据量前10检索对象）三次检索（关键词5个，时间选择近一年，留痕来源&留痕类型全选）
多个检索对象（留痕数据量前10检索对象）三次检索（关键词5个，时间选择近一年，留痕来源为企微和通话记录和短信，留痕类型为文本和音频和视频）
多个检索对象（留痕数据量前10检索对象）五次检索（关键词3个，时间空，留痕来源&留痕类型全选）
多个检索对象（留痕数据量前10检索对象）五次检索（关键词3个，时间选择近一年，留痕来源&留痕类型全选）
多个检索对象（留痕数据量前10检索对象）五次检索（关键词3个，时间选择近一年，留痕来源为企微和通话记录和短信，留痕类型为文本和音频和视频）

按机构检索，检索进度100%时的时间
导出大量数据（留痕数据写入pdf慢）

• 测试脚本准备（4天）
• 执行测试（1天）
• 编写测试报告（2天）

测试环境服务器信息：
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 24
On-line CPU(s) list: 0-23
Thread(s) per core: 1
Core(s) per socket: 1
座： 24
NUMA 节点： 2
厂商 ID： GenuineIntel
CPU 系列： 6
型号： 85
型号名称： Intel® Xeon® Silver 4216 CPU @ 2.10GHz
步进： 7
CPU MHz： 2095.077
BogoMIPS： 4190.15
超管理器厂商： VMware
虚拟化类型： 完全
L1d 缓存： 32K
L1i 缓存： 32K
L2 缓存： 1024K
L3 缓存： 22528K
NUMA 节点0 CPU： 0-11
NUMA 节点1 CPU： 12-23

                   total        used        free      shared  buff/cache   available

Mem: 32009 12103 18735 819 1169 18738
Swap: 3195 1631 1564

留痕结果页检索速度慢测试流程
数据量6千万
（一）接口响应时间测试

• 打开浏览器控制台-网络
• 按照不同场景/用例步骤执行操作
• 查看接口的“时间”列，时间大于3s的接口进行数据记录（复制curl）
• 将记录的数据发送至对应的后端研发人员
• 待研发优化后重复执行以上步骤直至接口响应时间满足产品要求或优化空间已有限

（二）渲染时间测试

• 打开浏览器控制台-性能，点击“录制”
• 按照不同场景/用例步骤执行操作，页面数据加载完成后点击“停止”录制
• 选中内存变化的区域，查看渲染时间并记录数据
• 将记录的数据发送至前端研发人员
• 待研发优化后重复执行以上步骤直至渲染时间满足产品要求或优化空间已有限

（三）整体效果测试

• 按照不同场景/用例步骤执行操作，查看从点击“检索”/“再次检索”至结果页数据加载完成的时间
• 时间大于3s的场景/操作步骤进行记录
• 将记录的数据发送至产品，待产品决定是否需要进一步优化（如不需要优化无后续步骤，如需要优化参后续步骤）
• 将较慢的接口或操作场景向研发说明，直至研发优化完成
• 待研发优化后重复执行以上步骤直至整体时间满足产品要求或优化空间已有限

数据量1亿
（一）接口响应时间测试

• 打开浏览器控制台-网络
• 按照不同场景/用例步骤执行操作
• 查看接口的“时间”列，时间大于3s的接口进行数据记录（复制curl）
• 将记录的数据发送至对应的后端研发人员
• 待研发优化后重复执行以上步骤直至接口响应时间满足产品要求或优化空间已有限

（二）渲染时间测试

• 打开浏览器控制台-性能，点击“录制”
• 按照不同场景/用例步骤执行操作，页面数据加载完成后点击“停止”录制
• 选中内存变化的区域，查看渲染时间并记录数据
• 将记录的数据发送至前端研发人员
• 待研发优化后重复执行以上步骤直至渲染时间满足产品要求或优化空间已有限

（三）整体效果测试

• 按照不同场景/用例步骤执行操作，查看从点击“检索”/“再次检索”至结果页数据加载完成的时间
• 时间大于3s的场景/操作步骤进行记录
• 将记录的数据发送至产品，待产品决定是否需要进一步优化（如不需要优化无后续步骤，如需要优化参后续步骤）
• 将较慢的接口或操作场景向研发说明，直至研发优化完成
• 待研发优化后重复执行以上步骤直至整体时间满足产品要求或优化空间已有限