注：
1. 程序员做的测试
2. 测试报告文档原稿在上传审核中，请等待
审核好了：https://download.csdn.net/download/yiquan_yang/12694138

1 概述

1.1 背景

系统的稳定性是系统长期稳定运行能力，需要时间累积才能度量。平台的某些问题需要达到一定时间、一定的使用量后才会暴露出来。如内存泄漏，系统运行过程中发现部分服务的部分接口会发生服务不可达的情况。
从而团队提出对平台进行稳定性分析，通过给系统施加一定业务压力大情况下，使系统持续运行一段时间，以此来检测系统是否稳定运行（下统称稳定性测试或测试）。

1.2 服务说明

平台运行的服务包括系统服务和业务服务，系统服务包括Consul、Redis、Cap、RabbitMQ、Exceptionless套件等，业务服务包括用户服务、基础数据服务、网关服务，详细见《xxx发布标准》。本次测试针对三个业务服务，对系统外界只有网关可视（测试对象统称系统或平台），故测试对象为一个服务。

1.2.1 服务器部署

本次测试采用单机环境，所有服务全部配置在同一台服务上，数据库部署在另一台机器上。

Manufacturer: Microsoft Corporation
Product Name: Virtual Machine
IP：192.168.4.57（业务服务）、192.168.4.253（数据库）
CPU：Intel® Xeon® Gold 5117 CPU @ 2.00GHz （物理CPU个数 1，核数：16）
Memory：16G

OS：CentOS Linux release 7.6.1810 (Core)
PostgreSQL：PostgreSQL 11.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit
Docker：Docker version 19.03.5, build 633a0ea
其他软件环境见1.3测试工具

1.2.2 服务配置

其中系统中存在大量配置，其中影响测试的配置包括：
xx：单服务接口最大并发数 设置为 1万
xxx：请求执行超时时间 设置为 30s
xxx：是否启用性能追踪组件 设置为 不启用
xxxxxx：是否启用服务接口缓存拦截 设置为 启用
Xxxxxxxx：是否启用集中式日志 设置为 不启用

1.3 测试工具

Apache JMeter（5.2.1）：测试客户端，作为虚拟用户脚本产生器（Virtual User Generator）、压力产生器（player）、用户代理（Agent）、压力调度和监控系统（Controller）、压力结果分析工具（Analysis）
1)安装前需要安装Java，本次测试使用jre1.8.0_241
2)客户端如需则自行汉化
3)安装服务资源监控器插件，从官网下载安装Plugins Manager，并安装jpgc – Standard Set
ServerAgent（2.2.1）：服务器Agent，提供服务器资源使用数据
1)服务器需要安装Java，本测试使用java version “1.8.0_241”
2)进入ServerAgent存放目录，使用命令“./startAgent.sh”启动Agent
3)需要确保端口4444能够访问，本测试关闭了服务器防火墙

1.4 稳定标准

在一定的配置情况下
CPU：单颗，16核
Memory：16G
在以上硬件环境下满足
1)系统指标
满足100个/s的最大并发。请求100%请求成功，且平均响应时间小于5s；
2)资源指标
在单位时间内（5s），CPU最大使用率不能持续超过95%，内存最大占用率不能持续超过95%。
1.5 关键字定义
1.6 排除干扰项
不考虑断电，硬件资源损坏情况

2 测试方案

本次测试采取负载测试、并发测试、可靠性测试。测试方案采取模拟真实用户使用场景，模拟指定人数在一定时间点击界面产生的请求数。
在并发10（单位个/s）、20、40、80、160、500、1000、2000的基准下，调整用户数（虚拟用户用一个线程，下统称线程数）、点击准备时间（用户点击时间模拟时间，下称Ramp-up单位秒）和用户点击次数（下称循环），例如10个用户，每个用户每5秒点击1次，则线程数为10，Ramp-up为5，循环数为1。详细测试策略请看2.1。

对登录、数据新增（用户）、编辑（用户）、获取（用户）和删除（用户）进行负载测试，获得其稳定负载值。
对全站使用策略100-100-1-1进行并发测试，挑选用户服务所有接口。基础数据服务中挑选和用户服务关联的功能接口5个，组织结构接口4个，和用户服务无关的行政区3个接口。具体接口请查看附件1。
对全站进行可靠性测试，根据以上测试接口，选择稳定的并发数后持续测试-模拟时长8+小时。
稳定性测试是通过运行状态和资源指标的2个方面来分析及评估系统的稳定性，请求记录项响应的时间平均值、最小值、最大值、标准偏差、异常（百分比）、吞吐量、接收、发送、平均字节数，服务器资源指标CPU、Memory，在此额外添加记录数据库数据。通过调试测试策略、分析实验数据得出相关系统稳定性的结论，从而达到平台能力验证、规划能力、性能调优、缺陷发现等目的。

评价定义
稳定：无异常，平均值和变成偏差差距较少且不高；
普通：无异常，平均值小于5秒，平均值和变成偏差差距较少；
一般：无异常，平均值大于5秒，平均值和变成偏差差距较大；
差：存在异常，异常率小于30%；
极差：存在异常，异常率大于登录30%；

2.1 测试策略

测试策略

2.2 测试脚本

测试脚本分为登录和服务接口两个线程组，模拟用户登录后进行系统。
1)在测试前定义测试配置变量，查看图2.2-1，使用变量

图2.2-1 定义线程组中配置变量

图2.2-2 使用线程组中配置变量
2)用户登录成功后将Token写入全局变量中，服务接口线程组统一使用该Token。
3)创建数据类接口，相关使用值在BeanShell预处理程序中创建，创建完成后在JSON提取器中提取相关值，供请求组装报文，例如用户，产生用户姓名请查看图2.2-3，使用查看图2.2-4，提取值查看图2.2-5。

图2.2-3 定义线程组中创建用户姓名变量

图2.2-4 使用线程组中创建用户姓名变量

图2.2-5 使用线程组中创建用户姓名变量
4)编辑、获取和删除接口需要的主键ID从创建请求成功后提取。
5)脚本中还包括HTTP头信息管理器(HTTP Header Manager)，相关运行结果项察看结果树（请求头，Body，Response结果）、用表格察看结果（请求开始时间、运行时间等）、汇总报告（样本、最小值、最大值、错误率等）、jp@pc-PerMon Metrics Collector（服务器资源监视器）、汇总图（请求时间管理：样本、中位数、平均值、90%百分比等）
6)整体脚本编写完成后，请查看图2.2-6。

图2.2-5 脚本一览

3 负载测试

3.1 测试样本

3.1.1 登录接口

1)查看结果树

登录接口（线程池100）

登录接口（线程池1000）

登录接口（线程池1500）

登录接口（使用多个策略连续测试-线程池1500）

2)使用多个策略连续测试

jp@pc-PerMon Metrics Collector 服务资源监控
3)100-1000-10-无线循环（10次+）

CPU占用在30%左右
内存在30%左右
4)100-1000-10-2 汇总图

中位数（所有请求响应时间的中间值可认为50%的请求）低于平均值和最大值的一般，比较稳定。
90%请求在15s内请求完成，在并发高的情况下响应时间会降低，一半以上的会大于6s。但是100%响应，无异常产生。

3.1.2 创建接口

创建用户（连续请求两次）
策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
100-1000-10-1 2001 79 41 262 20.40 0.00 30.36 8.75 20.55 295 稳定

各项测试策略表现的非常稳定

3.1.3 获取接口

此接口没有配置缓存拦截，数据直接读库

获取用户（连续请求两次）

各项测试策略表现的非常稳定

3.1.4 编辑接口

1)更新用户

更新用户（连续请求两次）

2)修改用户密码

修改用户密码

3.1.5 删除接口

删除用户（暂时无并场景）

3.1.6 分页接口

此处没有选择分页查看用户，是因为查询数据无数据，经排查是没有权限，但是搜索角色却可以。并且页大小为10，查询第一页没有考虑数据量大的情况，搜索比较靠后的页。此接口没有配置缓存拦截，数据直接读库

分页查询角色

3.1.7 其他接口

用户服务

比较突出的四个为评价“普通”，“一般”的。登录请求请看3.1.1

3.2 结果分析

3.2.1 稳定性分析

经过修复上一轮测试暴露出来的问题，目前登录、新增、编辑、查看、删除、分页等不同类型接口都有较好负载能力，满足团队当前对并发值100的期望值，部分接口平均响应时间未能满足要求，请求查看3.1。

3.2.2 解决方案

1)修改PostgreSql最大连接数，视服务器配置设定
在本次测试服务器环境下设定1000，能满足基本负载要求（基础数据平台）
参考资料：
https://stackoverflow.com/questions/30778015/how-to-increase-the-max-connections-in-postgres/32584211#32584211
2)修改服务事务，禁止在事务中添加执行长时间的代码，例如：大量RPC、HTTP、大量循环等。
事务使用方式请参考《xx平台文档库》
3)修改服务最小线程池值
在本次测试服务器环境下设定1500，能满足负载要求（基础数据平台）
参考资料：https://stackexchange.github.io/StackExchange.Redis/Timeouts.html
4)优化细节
登录后权限设定改为异步；
方法中添加返回值，返回类型为Task添加async关键字；
取消接口事务，如果零个或单个DML取消事务，其他情况事务中只含DML语句；
优化代码结构，防止重复代码或重复业务操作（如删除操作：Service判断是否存在、仓储层再次判断是否存在）；
获取类接口（执行时间久、修改频率低）添加服务端缓存拦截；
修改xxxxxxxx.json中接口并发数，MaxConcurrentRequests=1000
修改yyyyyyyy.json中管理Redis线程数值，本次测试为：minSize=100、maxSize=1000

4 并发测试

4.1 测试样本

100-100-1-1策略下测试整个服务

表3.2-1 负载测试汇总报告

图3.2-1 负载测试jp@pc-PerMon Metrics Collector

图3.2-2 负载测试汇总图

图3.2-3 负载测试报错日志

图3.2-4 吞吐量正序排序

图3.2-5 接收数据倒序排序

4.2 结果分析

测试一次用例总共耗时1分33秒，共4501一个请求，接口普遍正常，其中“根据角色和功能删除”、“根据角色Id删除对象功能”出现少量异常分别为1%、3%，错误信息请查看图“3.2-3”。接口的普遍中位数在500ms以上且标准偏差大在800ms左右，不考虑接口业务设计错误信息下，指标与当前版本要求差距不大。部分接口返回数据较大和吞吐量低的情况，更详细请查看可靠性测试。

5 可靠性测试

5.1 测试样本

5.1.1 全站可靠性测试

使用稳定的并发数持续运行-模拟时长8+小时
先采取策略100-100-1-1执行一段时间报错，由于单个接口100并发，49个接口总共并发数较大，调整策略为10-10-1-1，单接口10并发整站490并发，循环持续执行。

表3.3.1-1 汇总报告
修改后 相同测试样本，

修改前和修改后服务器消耗资源对比

图3.3.1-1 PerMon Metrics Collector-修改前

图3.3.1-1 PerMon Metrics Collector-修改后

修改前和修改后服务器内存消耗对比

图3.3.1-3 PerMon Metrics Collector-Memory-修改前

图3.3.1-3 PerMon Metrics Collector-Memory

5.1.2 创建接口类型可靠性测试

1)创建用户

表3.3.2-1 汇总报告
修改后 平均响应时间缩短计算器60%，吞吐量增加300%

图3.3.2-1 服务器资源消耗-修改前后对比
修改后：内存消耗稳定，且能够回收内存，之前需要运行1h23min，现在仅需27min，缩短67%的时间。

图3.3.2-2 服务器资源消耗-Memory-对比
2)创建功能

表3.3.2-2-1 汇总报告
修改后 平均响应时间缩短计算器57%，吞吐量增加270%

修改后：各项指标均运行平稳，其中内存消耗比较明显，之前需要运行58min，现在仅需20min，缩短65%的时间。

图3.3.2-2-1 服务器资源消耗
内存消耗比较：由于是单机部署，存在多个服务，此处只比较内存变化稳定性，修改后较修改前稳定。

图3.3.2-2-2 服务器资源消耗-Memory

5.1.3 编辑接口类型可靠性测试

表3.3.3-1 汇总报告
修改后 接口存在错误，并发下编辑同库同表同行数据，与本次测试的策略有关系。报错详情：This NpgsqlTransaction has completed;it is no longer usable. 限制因素：数据库行级锁限制或并发下事务处理方案需优化

服务器资源消耗对比

图3.3.3-1 服务器资源消耗
内存消耗对比：修改后编辑用户前期内存消耗正常，在程序后期出现错误后内存消耗严重，和本次测试策略有关系。

图3.3.3-2 服务器资源消耗-Memory

5.1.4 获取接口类型可靠性测试

。。。

5.1.5 分页获接口类型可靠性测试

…

5.2 结果分析

5.2.1 概况

本次测试计划测试时长为8h+，实际测试时长为7小时8分钟，总共发起请求267387个，吞吐量为10.4/s，平均响应时间900ms，错误率0.5%，平均发送速率6.61KB/s，接收速率2425KB/s。
数据库数据无异常。

假设系统常用在线用户10人，每人平均每分钟点击20次，每天平均在线时长10分钟，13天

1)服务器资源CPU
服务器资源中CPU表现稳定，在测试后半段出现满负荷情况；
2)服务器Memory
服务器内存单位时间内平缓但总体呈上逐步升趋势；
3)服务器Disks I/O
服务器磁盘I/O比较稳定，测试用例循环测试的启动初期会出现一定的波动；
4)服务器Swap
服务器Swap在服务启动初期会暂用比较高资源，在服务运行过程中逐步下降；
5)服务器TCP
服务器TCP连接数在运行过程中一直保持在4000个连接左右，可能是影响吞吐量的因素之一；
6)Network I/O
网络I/O比较稳定，总体上没有太多的异常。

5.2.1.1 问题

1)服务器资源占用会越来越多
从图3.3-2 PerMon Metrics Collector-CPU、图3.3-3 PerMon Metrics Collector-Memory可以观察到CPU在测试后期出现异常，而内存逐步上升，在1h40min、3h、4h20min时出现一定下降，原因是测试循环和下一个循环的间隔，系统可能回收了资源。停止服务请求在相隔一定时间（8h+）后再次测试，资源占用情况并未好转（测试登录服务报错）。

2)服务吞吐量较低
在负载测试和并发测试中，虽然请求在100并发下都能真确响应，但响应时间长，在可靠性测试中实际吞吐量为10.4个每秒，考虑到不同类型的接口场景不同受影响因素不同，该值有一定不准确性。
3)服务出现的异常

根据角色和功能删除权限 20.50%
根据角色Id删除对象功能 2.98%
从数据库获取权限数据 0.09%
获得用户列表 0.09%
刷新用户缓存数据 0.09%
分页获取用户数据 0.04%
删除用户 0.04%
根据条件查询所有角色 0.04%
获得用户数据权限 0.02%
获取当用用户角色权限 0.02%

4)部分接口响应时间长
“从数据库获取权限数据”、“分页获取用户数据”等。

5.2.2 不同接口类型测试

由于全栈可靠性测试发现问题“服务器资源占用会越来越多”，故而进一步测试，选取压力测试里面增加、编辑、获取、分页获取四种类型接口进行可靠性分析。总体服务器资源消耗严重在于内存会持续增加，最终导致服务器宕机。
根据测试数据可得出以下结论
1)服务器消耗瓶颈在于内存，CPU、TPC、I/O等比较稳定；
2)创建类接口会导致内存泄露；
3)编辑类接口总体上稳定，但长期观察内存有缓慢上升趋势，但TPC连接数也同步上升，需要深入Linux调优排查；
4)获取类接口可以长时间稳定运行；
5)接口吞吐量与接口响应时间正比，响应时间长的接口吞吐量低，比较突出的“分页获取用户数据”、“获得用户列表”、“登录”、“从数据库获得权限数据”、“获取组织机构List”。而相对于不同接口类型，获取类的接口比操作类的接口快。

5.2.3 解决方案

1)登录问题
Token过期后大量请求导致系统卡顿
原因，Token保活机制在其最后5分钟内触发，对比时间取得是请求Header中的时间，而保活操作取得是缓存时间，导致Token失效后所有请求都触发保活操作，消耗大量资源。
解决方案：时间统一用缓存中时间
2)DotNetty组件
每次Rpc会长留一个byte[]的变量（客户端和客户端都会），记录已发送字节大小。
修改方案修：不记录已发字节数且Rpc结束之后调用ReferenceCountUtil.Release(buffer);清除Rpc过程中产生的垃圾。
修改DotNetty服务端和客户端，涉及模块Surging.Core.DotNetty、Surging.Core.DotNettyWSServer、Surging.Core.Protocol.Http、Surging.Core.Protocol.Mqtt、Surging.Core.Protocol.Udp、Surging.Core.DNS。
3)禁用Surging性能追踪组件。
原因：使用微软DiagnosticListener组件，记录记录锚点数据用于记录性能追踪数据，BUP目前未启用surging的Skywalking（不完善），所以数据一直长留在内存中，
4)集中式日志
当不使用集中式日志时需要在配置中不启动
5)未使用Module影响
xxxxxxxx.json中Packages->Using配置：ServiceProxyModule、SkywalkingModule

6)Surging生命周期管理引起的内存泄漏
总体上修改后提升了稳定性（详情数据查看3.3中修改后测试结果），首先CPU和Memory振幅变小，系统运行平稳，其次平均响应时间大大缩短，最好为200ms，再者吞吐量提升明显最大接近500个/s。

5.3 稳定测试-可靠性测试

5.3.1 平稳-高并发-平稳

选择接口采用“平稳-高并发-平稳”的测试策略进行测试，设置并发数为1-5-10-15-10-5-30-60-5（接口35个，实际并发高于设定值）。

测试结果

结论：内存能够回收，证明在高并发后能够回收内存资源；

5.3.2 长时间测试

选择部分接口进行长时间运行测试，1千万左右请求

最终内存消耗情况

最终系统运行时间

结论：能够长时间运行，且请求结束能够能存占用情况能够回归到稳定水平。

6 总结

经过三种不同测试方法负载测试、并发测试、可靠性测试。
负载测试证明能平台框架在不同类型接口下能满足预定的稳定指标；
并发测试证明平台所有业务接口能够满足预定的稳定指标；
可靠性测试证明平台能够长时间运行，满足预定的稳定指标

7 附录

附录1-测试接口列表

编号 服务名 接口名 接口URL
1 用户 登录 POST /api/user/login?servicekey=User
2 获得当前登录用户信息 GET /api/user/getcurrentuserinfo?servicekey=User
3 创建用户 POST /api/user/createuserinfo?servicekey=User

详细请翻阅附件2-测试脚本

附录2-测试脚本

JMeter打开

··已删除jmx文件··

PostMan打开
··已删除 postman_collection.json··

附录3-数据库数据统计

原始测试数据库是从253已存库备份而来
1.数据库
编号 数据库
大小
测试项 bup_xxx_stability bup_cap_stability bup_yyy_stability
1 测试前数据 15 MB 8157 kB 15 MB
2 负载测试 15 MB 8245 kB 20 MB
3 并发测试 15 MB 8789 kB 23 MB
4 可靠性测试 26 MB 31 MB 57 MB
2.数据库表大小
编号 数据库 表名 原始 负载测试 并发测试 可靠性测试
1 bup_basedata_stability cap.published 16 kB 16 kB 16 kB 16 kB
。。
3.数据库表行数
编号 数据库 表名 原始 负载测试 并发测试 可靠性测试
1 bup_basedata_stability Xxx_t_xxxx 348 348 348 348
…