系统性能测试流程详细

性能之前：系统结构的演变介绍

参考：https://cloud.tencent.com/developer/article/1511594

总结一点：系统越演化越复杂，后台的服务这部分越来越细。导致用户压测量比较大的时候，节点越有可能出现问题。

正文开始------------------------------------------------

性能测试详细流程

基本定义：是通过自动化的测试工具（jmeter、LR）模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试。

前期：准备工作

第一步：确定需求——需求调研人员、产品经理、测试组长、项目经理

第二步：分析需求、阅读需求

1. 分析交易、指标、场景以及环境

有需求说明书，没有说明书。

目前测试到线上的几大环境:

dev环境：开发环境

sit环境： 集成测试环境

uat环境： 用户验收环境

• 分析交易：性能的测试范围，被测的api接口

• 选择系统中核心的交易：银行，财务，证券等金融系统有关的模块

• 项目经理确认一下
• 系统跟资金有关的系统业务确认，保证用户的财产安全性。

• 互联网软件：百度网盘

• 用户常使用的模块要做性能：网盘其实大众使用最多的模块无非就是上传和下载这些模块。

• 选择系统中业务路径较长的交易：OA办公系统(行政采购，登陆-生成采购订单-审核【领导审核，财务审核】-->采购订单-->入库订单)

• 摘取路径特别长的情况来进行，因为路径越长，越有可能出错，所以也要做性能测试。

• 选择系统中业务量较大的交易（pv（page view）、uv(user view：运维手里) --> dau日活、mau月活）: 购物软件: pv和uv添加计算器埋点程序，手机用户的信息。

购物车：10万uv

结算：500万uv

物流：300万uv

通过每天的用户使用量来评估性能哪些模块要做性能测试。

上述购物车和物流两项要做性能测试。

• 埋点：

• 客户端埋点：手机app里面的模块进行埋点：添加监听器 count = count + 1 user=user + "张三"
• 用于后期的大数据分析和大数据精准推送。【通过埋点来手机个人数据，用于后期的数据分析和推送】
• 
  

• 服务器埋点：通过历史的数据进行个人行为分析来分析下个月的商品购买情况

所有的埋点都是为了收集指标数据。

• 没有需求说明书：竞品分析

• 参考同行业其他软件指标，进行比例调整。进行第一步测试

1. 分析指标：tps、响应时间、并发用户数、hps（hit per second）、qps、系统资源使用率、成功率

1. 业务指标

• Tps（transactions per second）：每秒处理的事务数（衡量系统的核心指标，也是性能处理能力的关键指标）
• 以单接口定义为事务举例，每个事务包括了如下3个过程：

• 客户端向服务器发请求
• 服务器自己的内部处理（包含应用服务器、数据库服务器等）
• 服务器返回结果给客户端
• 越高越好（说明cpu的处理的事务能力就越高）
• 标准指标：>500

• 系统用户数（在数据库中存在的总用户数），在线用户数（今天有多少用户使用这个系统，dau等价），并发用户数（针对某个场景，此时此刻正在并发的）：指的是现实系统中同时操作业务的用户，在性能测试工具中一般称为虚拟用户

• 每个人人手一个12306账号，今天一天有2亿人登陆了账号做了一些查询操作，但是此时此刻就有20万人同时查询北京-上海的高铁。

系统：14亿（在数据库中存在的这么一个用户量，不管死了还是活的）

在线（日活）：2亿

并发：20万（某时某刻，有多少用户同时去做某件事情）

• 大型系统(业务量大、机器多)做性能测试5000个并发用户就够了，中小型系统做性能测试1000个并发用户就足够了。

• hps（hits per second）：每秒点击率 = qps
• qps（query per second）：每秒查询请求数,越高越好，>=500
• 系统的资源使用率：cpu、内存、磁盘
• 成功率：99%~100%:后面这项指标如果不是100%,表示本轮测试无效。

• 需要多测试几次，排查是否是硬件指标问题
• 如果是没有达到100%，本轮测试无效，后面的其他指标不用看了，无效

• 响应时间：

• 接口时间 (0.5s)+ 页面渲染时间（2.5s） < 3s
• 一般接口时间：500ms ~ 800ms范围是合理的
• 越快越好

b. 硬件指标：

cpu：<75% （top）

内存：<75% (free)

磁盘: <75% (df -hT)

io： iostat

进程： ps -ef

端口： netstat -ano |grep 8080

评估性能通不通过：1.成功率100% 2.tps,qps,rt,pmc是否合格

1. 分析场景：

性能测试前提条件：要接口和自动化测试要通过。

新增文章（1500），全栏目发布（1200），文章的编辑修改（1000），全文查询（2000）

登陆，买入理财，贷款，修改个人

• 单交易基准场景（接口测试）：1个用户进行单个交易，冒烟测试

• 目的：验证无压力的情况下，系统的各项指标是否正常，验证该交易是否正常请求
• 为了保证后面性能测试的前提。如果接口都有问题，后面的性能测试没法实现。

• 单交易负载场景：多个用户进行单个交易，10-15min

• 目的：验证单个交易的最大处理能力，tps。验证单个模块的最大极限值。
• 测试标题：100个用户压测-登陆-5min
• 监控指标：

• 硬件指标：cpu,内存，磁盘，tcp
• 业务指标：tps,qps,hps,吞吐量，响应时间

• 混合场景: 多个用户进行多个交易，30min -- 淘宝，京东（618,11.11）【模拟多用户在集中的某个时间点，进行集中并发测试。测试在短期时间内系统是否能处理这么大的并发压力】（2000）

• 目的:验证整个系统的最大处理能力-（极限测试）验证系统处理的极限值

• 稳定性场景（疲劳测试）: 选择单交易负载场景或者混合场景下最大压力的80%（二八原则）【验证测试系统在长时间情况的压力下，有没有问题】

最高极限的80%的用户集中在20%的时间内做这些交易测试。（2000 * 0.8 =1600 并发4H或者5H）

• 单交易稳定性
• 混合交易稳定

2. 分析环境：性能的测试环境尽量独立，且保持与生产（线上）环境一致

• 客户端环境

• 软件环境：测试工具jemter、lr，操作系统win、Java的环境jdk、监测工具spotlight、、xshell、navicat
• 硬件环境：cpu、内存、磁盘

• 服务端环境

• 软件环境：应用服务器tomcat/weblogic、数据库mysql/oracle、Java的环境、监测工具（nmon）、nginx、操作系统linux
• 硬件环境：cpu(top)、内存(free)、磁盘(df -hT)

用例设计和开发：

第三步：编写测试用例：预置条件、测试步骤、预期结果和实际结果（用例四要素）、用例标题、用例的优先级、用例的编写人

注意事项：

jmeter脚本配置：

1.仅一次控制器

2.吞吐量控制器

3.固定定时器： 模拟人工在页面的停留时间，思考时间 think time

4.同步定时器：集合点，在集齐xx用户后，执行并发操作。

• 不同的场景对应不同的用例，只要涉及到变量的情况下就存在不同的场景

1. 单交易基准场景：张三用户购买微信理财产品

• 用例标题1：1vuser-理财-5min
• 预置条件：

• 张三用户能够正常进行登录请求
• 张三用户的余额中至少有3000元
• 有可供购买的微信理财产品
• 在张三用户请求理财交易时无其他用户进行系统各项交易请求

• 测试步骤：

• 调试脚本和增强脚本，首先在jmeter线程组下添加对应的理财交易请求信息 ，包含请求方式、请求参数、请求路径、请求端口等等，接着在http请求下添加响应断言以及查看结果树，最后添加cookie管理器获取用户的身份信息，调试成功后，在监听器下添加tps组件、pmc组件以及聚合报告
• 配置场景，在线程组调度器下配置场景持续执行5min，线程数为1
• 收集结果指标，使用pmc组件收集cpu、内存、磁盘使用率

• 预期结果

• 理财交易请求成功
• 系统的各项硬件资源基本稳定，无负载情况

2. 单交易负载场景-同时并发：每天上午10点，有100个用户购买微信理财产品

• 用例标题1：100vuser-理财-10min-同时并发
• 预置条件：

• 100个用户能够正常进行登录请求
• 100个用户的余额中至少有3000元
• 有可供购买的微信理财产品
• 在100用户请求理财交易时无其他用户进行系统各项交易请求

• 测试步骤：

• 调试脚本和增强脚本，首先在jmeter线程组下添加对应的理财交易请求信息 ，包含请求方式、请求参数、请求路径、请求端口等等，接着在http请求下添加响应断言以及查看结果树，同时添加cookie管理器获取用户的身份信息，最后添加csv组件完成参数化配置，调试成功后，在线程组下添加同步定时器完成集合点的配置，最后在监听器下添加tps组件、pmc组件以及聚合报告
• 配置场景，在线程组调度器下配置场景持续执行10min，线程数为100
• 收集结果指标，使用tps组件收集tps、聚合报告收集响应时间、错误率等、pmc组件收集cpu、内存、磁盘使用率

• 预期结果

• 理财交易请求成功
• 响应时间小于2s，tps大于250以上，CPU小于70%，内存小于70%，磁盘小于80%

3. 单交易负载场景-阶梯型并发

• 用例标题1：100vuser-理财-15min -阶梯性并发
• 预置条件：

• 100个用户能够正常进行登录请求
• 100个用户的余额中至少有3000元
• 有可供购买的微信理财产品
• 在100用户请求理财交易时无其他用户进行系统各项交易请求

• 测试步骤：

• 调试脚本和增强脚本，首先在jmeter递增式线程组（stepping Thread）下添加对应的理财交易请求信息 ，包含请求方式、请求参数、请求路径、请求端口等等，接着在http请求下添加响应断言以及查看结果树，同时添加cookie管理器获取用户的身份信息，最后添加csv组件完成参数化配置，调试成功后，在监听器下添加tps组件、pmc组件以及聚合报告
• 配置场景，在递增式线程组下配置每隔5min递增20个用户，一直增加到总线程100时执行场景15min
• 收集结果指标，使用tps组件收集tps、聚合报告收集响应时间、错误率等、pmc组件收集cpu、内存、磁盘使用率

• 预期结果

• 理财交易请求成功
• 响应时间小于2s，tps大于250以上，CPU小于70%，内存小于70%，磁盘小于80%

4. 混合场景，每天上午10点，有100个用户在线访问理财系统，其中50个用户进行理财交易，20个用户进行还款交易，30个用户进行借款交易

• 用例标题：100vuser-理财&还款&借款-30min
• 预置条件：

• 100个用户能够正常进行登录请求
• 100个用户的余额中至少有3000元
• 有可供购买的微信理财产品
• 在100用户请求理财、还款、借款交易时无其他用户进行系统各项交易请求
• 至少准备36000条借款记录

• 测试步骤：

• 调试脚本和增强脚本，首先在jmeter线程组下添加对应的理财、还款、借款交易请求信息 ，包含请求方式、请求参数、请求路径、请求端口等等，接着在http请求下添加响应断言以及查看结果树，同时添加cookie管理器获取用户的身份信息，最后添加csv组件完成参数化配置，调试成功后，在http请求前添加吞吐量控制器完成5:3:2的交易配比，在监听器下添加tps组件、pmc组件以及聚合报告
• 配置场景，在线程组下配置总线程100，吞吐量控制器以5:3:2的百分比模式进行配置
• 收集结果指标，使用tps组件收集tps、聚合报告收集响应时间、错误率等、pmc组件收集cpu、内存、磁盘使用率

• 预期结果

• 理财、还款、借款交易均请求成功
• 总体指标，具体参考前期调研的

第四步：准备测试数据和准备脚本

• python脚本：open或者xlwt或者pymysql + faker工具集中造批量数据存储在文件中

import pymysql

con = pymysql.connect(host="192.168.1.237",user="root",password="root",database="finance")

cursor = con.cursor()

user_sql = "insert into user  values(%s,%s,%s,%s,%s,%s,%s,%s,%s,%s)"
bank_sql = "insert into bankcard  values(%s,%s,%s,%s,%s,%s,%s)"
f = open(file="D:\\user.txt",mode="w+",encoding="utf-8")

for i in range(100):
    user_param = [4 + i,"jason" +  str(i),"jason","e10adc3949ba59abbe56e057f20f883e",
                  110101199703142123 + i,12345678912 + i,"[e-mail]","666666",0,"优秀"]

    bank_param = [i,"中国建设银行",1,1234567891024567 + i,4 + i,40000000,1]

    f.write("jason" + str(i)+";e10adc3949ba59abbe56e057f20f883e;" + str(4 + i) + "\n")

    cursor.execute(user_sql,user_param)
    con.commit()
    cursor.execute(bank_sql,bank_param)
    con.commit()

cursor.close()
con.close()
              

                
from faker import Faker
fa = Faker("zh_CN")

f  = open(file="a.txt",mode="w+")

for i in range(500):
    f.write(fa.name()+";a2s98df456a1s230fasd98f456120;"+str(i))
    f.write("\n")

f.close()

• 通过数据库存储过程来集中造数据。

delimiter $$
create   procedure  addUser()
begin
declare num int;
set num = 1;
while num < 100 do
	insert into `user` values(num+7,concat("jason",num) ,
	concat(num,""),
	"e10adc3949ba59abbe56e057f20f883e",
	110101199703142123 + num,
	"15188888800",
	concat(num,"@qq.com"),
	"666666",
	1,"良好");
	set num = num + 1;
end while;
end $$

call  addUser()



DELIMITER  $$
CREATE  PROCEDURE  addBank()
BEGIN
DECLARE  b INT;
SET  b = 1;
WHILE  b < 100 DO
	INSERT INTO bankcard  VALUES(b + 2,"中国建设银行",2,12345678945213124 + b,b + 5,40000000,1);
	SET b = b + 1;
END WHILE;
END $$

中期：执行环节

• 第一步：根据前期设计的用例进行执行

LR：vugen（脚本录制、脚本编写）、controller（设计场景、执行场景）、analysis（收集结果）

1.单交易基准场景

2.单交易负载场景

• 同步并发场景，集合点：

• number of :按组分组的集合点数
• timeout in milliseconds：等待超时时间

• 固定等待：线程数必须大于分组集合点数，且等待超时时间为0
• 隐式等待：不管线程数和分组集合点数谁大谁小，只要到了等待超时时间就立马执行剩余的线程

• 递增式并发场景：
• 
  

1. 混合场景：使用吞吐量控制器完成交易分配
2. 
   

如何确定混合测试场景的各项交易占比？？？

• 已上线系统：可以以实际的线上真实用户的交易数据作为性能测试混合场景的交易占比
• 未上线系统：

• 张嘴去要：产品那边，运维人员，项目经理
• 竞品分析，同类型项目的参考
• 内测或者灰度发布
• 预估混合场景的测试交易--》预估混合场景的总并发1000--》预估混合场景的各项交易占比40-50%，其次的交易10-20%-》预估完成之后，将实际混合场景测试的各项指标进行组内评审

jmeter的卡顿问题：

cpu,内存问题：

内存问题：

jmeter本身是java写的，启动过程需要用内存空间，默认256MB，如果内存不够，jmeter肯定会卡。

cpu: 因为cpu的处理频率比较低（2.5GH~ 2.7GH）,这种频率的限制，导致cpu同一时刻，只能并发200~300个线程用户。jemter配置1000个用户没法一下处理过来。

1. 分布式负载场景，在同一个局域网下
2. 由于我们笔记本电脑的配置问题，内存不够，

另外由于cpu的配置问题，1个cpu + 4个内核 ,处理频率: 2.4~ 3.0GHZ.

cpu一次性最多也就200~300个线程。1200线程数量，jmeter是没有办法一次全部并发。

所以就需要多台机器一起执行。 1500用户，单台最高并发300，所以需要5台执行机。

这其中涉及到一个master调度机， slave执行机。

• 调度机：发号指令，只有一台

• 将每台执行机的ip地址以及端口号添加到jmeter/bin目录下的jmeter.properties文件中的remote_hosts

remote_hosts=192.168.1.56:8888;192.168.1.7:8888

• 启动调度机的jmeter-server.bat服务

• 执行机：执行命令，有多台
• 获取每台执行机的ip地址以及端口号（在jmeter/bin目录下的jmeter.properties文件中的server_port）
• 
  

server_port=8888

• 启动每台执行机的jmeter-server.bat服务

注意事项：

• 调度机和执行机的jmeter版本以及jdk版本保持一致
• 调度机和执行机既可以用自己的笔记本也可以直接用服务器
• 调度机中的脚本执行文件要在每台执行机中有，且路径保持一致
• 调度机中的参数化文件要在每台执行机中有，且路径保持一致
• 所有虚拟网卡全部关闭

第二步：收集结果：jmeter自带工具（pmc）,spotlight,nmon，命令（top,free,df -hT,ps -ef,netstat）

1. 第三方工具：spotlight（linux、win）、nmon（linux）
2. free -s 1 -c 10
3. top
4. 命令行执行：jmeter -n -t 【脚本路径】 -l 脚本执行结果存放路径 -e -o 图像化结果存放路径

第三步：分析指标与定位问题（bug篇）

1. 分析指标：将各个场景执行的结果数据与前期调研的结果指标数据进行比对
2. 性能问题定位：

常见面试问题：如果出现了性能问题，该怎么定位，或者如何识别性能瓶颈？

• 系统方面：看日志，日志级别：info、error、warn、fatal

• 日志一：测试工具应用日志：jmeter.log

常见问题一：

• 命令行：jmeter -n -t xxx.jmx -l yyy.jtl -e -o result(文件夹)

• ERROR - kg.apc.jmeter.perfmon.PerfMonCollector: Perfmon plugin error:

• 服务器端没有serverAgent这个服务，导致PMC没法监控。
• java.net.ConnectException: Connection timed out: connect
• 解决方法：场景执行之前需要启动serverAgent服务
• 常见问题二：修改jmeter.properties --> -Xms -Xmx 最大内存最小内存
• 改jmeter.bat -->
• set HEAP=-Xms1024m -Xmx1024m

• set NEW=-XX:NewSize=1024m -XX:MaxNewSize=1024m

• 日志二：被测系统应用日志，日志目录需要和开发进行确认：

• 常见问题一：

• 说明：以上现象为内存溢出问题，当JVM遇到与资源利用有关的问题时，会抛出该错误。更具体地说，当JVM花太多时间执行垃圾回收并且只能回收很少的堆空间时，就会发生该错误。

• 优化方法：1.除了使用-设置堆内存外Xms1g -Xmx2g，尝试
• -XX:+UseG1GC -XX:1GHeapReginotallow=n -XX:MaxGCPauseMillis=m -XX:ParallelGCThreads=n -XX:Cnotallow=n
• 2.优化代码减少 尽可能重用现有对象以节省一些内存

• 3.检查代码使用while循环，不停的new对象，占用了大量的内存

• 说明：以上现象为数据库锁等待超时问题

原因：

解决方法：

悲观锁：直接杀死其中的一个进程，方便其他进程进行使用。

或者直接重启服务器。所有进程从0开始。

乐观锁

1.添加线程的优先级别，低优先级会给高优先级的线程让步。

2. 修改锁等待超时时间 SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait_timeout'; set global innodb_lock_wait_timeout=100;

• 日志三：中间件输出日志：tomcat（中小型系统）、weblogic（大型系统）

• 常用命令：tail -f 文件名称 | grep 'error'，实施监控日志命令

• 日志四：数据库常用日志：

说明：通常，sql语句效率不高，有以下两个原因： 第一：sql语句本身的问题，比如大sql，连表查询等； 第二：索引问题，没有加索引，或者索引失效(不起作用，或起反作用)

• 环境方面

• 系统的硬件资源：监控系统硬件资源，包括cpu、内存、磁盘占用率
• 测试工具的版本：jmeter、jdk版本
• 系统的网络带宽：网络运维工程师、网络监控工具监控、nmon

查看nmon分析文件中NET sheet页中total-read和total-write的绝对值之和，若total-read和total-write的绝对值之和约为60+320=380KB/s，网络带宽是1000Mb/s,所以需要转换：380KB/s *8=3040Kb/s / 1024 =2.97Mb/s，与网卡带宽1000Mb/s比较即可，占比只达到0.3%。

• 连接池的大小

第四步：提交bug，性能调优（性能调优工程师或性能诊断工程师）

• 1.系统架构(系统架构师)（将单台服务架构进行优化优化成多台的微服务的执行架构）加服务器

• 使用nginx + 微服务（前端服务器 + 逻辑处理层服务器： springboot，nacos,springcloud） + 内存数据库中间件（redis） + nacos,zk,springcloud + db2 + weblogic

• 将大型应用拆解小应用，导致服务器越来越多。但是某个节点压力小多了。

• 网络 ： cdn静态节点加速。就是将不变的一些文件在全国各地的服务器都进行实时同步一份。当地的用户就可以直接访问当地的云服务器，没必要将请求发送到总服务器。

• 典型的实现技术：oss存储技术。

• 数据库：

• 使用多台数据库进行数据读写分离（数据库服务器压力），分库分表存储（分摊表的压力）。(mycart)加快访问速度。
• 
  

• 程序和算法（开发自己来进行优化：review 代码审查）（对程序员进行建议）

• 数据结构：红黑，二叉树，哪个最优用哪个
• 程序：一个循环能解决不用两个

• 在开发代码层面上，如果循环和判断过多，导致空间复杂度和时间复杂度就越高。

比如:冒泡排序：如果单层循环能解决的就不用两层循环来做。这样会节省代码在执行上的空间复杂度和时间复杂度。

• 3. 数据库层来进行。

• 读写分离： 分多个数据库
• 分库分表： 分多个表多个库存储
• sql语句：

• 1.严禁使用*代替，查询需要多少字段就用多少。

select  * from user;                  禁止使用*号查询   --阿里规范sql第一条
select  username,password   from user;    用多少数据就查询多少字段

• 2. 多层嵌套查询的结构，优化成子查询。(将其中的一部分查询结果使用变量来进行赋值，在后期查询中可以使用数据来查询)

• # 不建议使用

• SELECT *  FROM exam e   WHERE e.grade = (SELECT max(grade) FROM exams)

# 优化
SELECT @m := (select  max(grade) from exam ); 
# 先将查询最大分数赋值给变量m
SELECT *  FROM exam e  WHERE e.grade = @m;    
              不建议使用
• SELECT *  FROM exam e   WHERE e.grade = (SELECT max(grade) FROM exams)
• 优化
• SELECT @m := (select  max(grade) from exam );
• 先将查询最大分数赋值给变量m
• SELECT *  FROM exam e  WHERE e.grade = @m;

• 3.使用存储过程（相当于python的方法，函数）来把sql语句进行预处理。存储过程好处：可以将sql语句进行先处理，变成模板放在数据库里。直接调用即，可以将复杂语句事先放到数据库进行存储
• 
  

• cursor.execute("select *  from user")  编译 --> 查询

delimiter $$
create   procedure  addUser()              
begin
declare num int;
set num = 1;
while num < 100 do
	insert into `user` values(num+7,concat("jason",num) ,
	concat(num,"贾生"),
	"e10adc3949ba59abbe56e057f20f883e",
	110101199703142123 + num,
	"15188888800",
	concat(num,"@qq.com"),
	"666666",
	1,"良好");
	set num = num + 1;
end while;
end $$

call  addUser()					

con = pymysql.connect(host,user,password,database)
cursor = con.cursor()
#  在这一步直接调用数据库里已经编译好的存储过程，速度相当的快
data = cursor.execucte("call addUser()")                                 addUser()  调用方法

• 4.常用字段使用建立索引然后进行查询。防止进行全文查询。

EXPLAIN SELECT  * FROM  USER  WHERE  phone = "13345678912";
你会发现上述的查询会查询很多次才找到这条数据。那么就可以给这个字段添加一个索引，
来加快查询速度。
# expalin 慢查询的方式来解析每条sql执行的过程
#  如果创建索引
CREATE  INDEX   u_name  ON   `user`(username);
CREATE  INDEX  phone  ON `user`(phone);
EXPLAIN SELECT  * FROM  USER  WHERE  phone = "13345678912";    
再次查询这个数据，会发现值查询1次就找到这个数据了，速度比较全文查询要快
-- 开启时间记录
SHOW VARIABLES  LIKE  "profiling";

-- 开启时间记录
SET  profiling = 1;

-- 展示刚才查询数据的过程和查询时间
SHOW  PROFILES;

• 5.服务器配置上的优化（最常用）
• 数据库连接超时问题：
• 调整连接池的最大池参数： max_connect_pool = 150
• c3p0-config.xml  
• druid-server.properties 
• 找到配置文件，直接修改最大参数即可
• OutOfmemoryError: 内存溢出异常
• 修改java虚拟机的运行内存： -Xms: 1G    (最小内存)   -Xmx: 4G(最大内存)
• java  -Xms1G（系统运行的最小内存）      -Xmx6G（系统运行的最大内存）    -Xss100m(栈空间的最大内存)   -jar   finance.jar
• stackoverflowError:栈空间溢出异常
• 修改栈空间的运行内存
• 网络响应时间过长：RT
• 优化路由器和交换机的网络架构
• 提高整体机房的网络带宽： 100G -->   200G
• 抖音，快手，大型企业视频比较多机房的网络带宽： 45TB =  36,700,160 MB

• 优化：
• 将finance的启动内存：  java  -jar     -Xms1g   -Xmx10g  -Xss1g  finance.jar   ( jar  -xvf      ,jar  -cvf )
• 更改druid数据库连接池的最大参数： spring  .  datasource.druid.max_active:   100
• 将数据库的所有常用字段添加了索引： create  index    名称   on   表(字典);

第五步：回归测试

• 后期：验收环节
• 第一步：验收测试，编写测试报告
• 第二步：预发布上线：其实就是测试环境和线上的缓冲过程
• 第三不：正式上线，跟踪测试

• 性能测试方案/性能测试计划：测试进度、测试人员、测试的工具、测试的环境、测试的范围、测试的风险、测试的通过准则、测试的策略、测试的成本、测试场景、测试指标