2023年7月11日发(作者：)

Web服务稳定性测试负载测试可靠性测试⽅案测试报告1 概述1.1 背景系统的稳定性是系统长期稳定运⾏能⼒，需要时间累积才能度量。平台的某些问题需要达到⼀定时间、⼀定的使⽤量后才会暴露出来。如内存泄漏，系统运⾏过程中发现部分服务的部分接⼝会发⽣服务不可达的情况。从⽽团队提出对平台进⾏稳定性分析，通过给系统施加⼀定业务压⼒⼤情况下，使系统持续运⾏⼀段时间，以此来检测系统是否稳定运⾏（下统称稳定性测试或测试）。1.2 服务说明平台运⾏的服务包括系统服务和业务服务，系统服务包括Consul、Redis、Cap、RabbitMQ、Exceptionless套件等，业务服务包括⽤户服务、基础数据服务、⽹关服务，详细见《xxx发布标准》。本次测试针对三个业务服务，对系统外界只有⽹关可视（测试对象统称系统或平台），故测试对象为⼀个服务。1.2.1 服务器部署本次测试采⽤单机环境，所有服务全部配置在同⼀台服务上，数据库部署在另⼀台机器上。Manufacturer: Microsoft CorporationProduct Name: Virtual MachineIP：192.168.4.57（业务服务）、192.168.4.253（数据库）CPU：Intel® Xeon® Gold 5117 CPU @ 2.00GHz （物理CPU个数 1，核数：16）Memory：16GOS：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-bitDocker：Docker version 19.03.5, build 633a0ea其他软件环境见1.3测试⼯具1.2.2 服务配置其中系统中存在⼤量配置，其中影响测试的配置包括：xx：单服务接⼝最⼤并发数 设置为 1万xxx：请求执⾏超时时间 设置为 30sxxx：是否启⽤性能追踪组件 设置为 不启⽤xxxxxx：是否启⽤服务接⼝缓存拦截 设置为 启⽤Xxxxxxxx：是否启⽤集中式⽇志 设置为 不启⽤1.3 测试⼯具Apache JMeter（5.2.1）：测试客户端，作为虚拟⽤户脚本产⽣器（Virtual User Generator）、压⼒产⽣器（player）、⽤户代理（Agent）、压⼒调度和监控系统（Controller）、压⼒结果分析⼯具（Analysis）1)安装前需要安装Java，本次测试使⽤jre1.8.0_2412)客户端如需则⾃⾏汉化3)安装服务资源监控器插件，从官⽹下载安装Plugins Manager，并安装jpgc - Standard SetServerAgent（2.2.1）：服务器Agent，提供服务器资源使⽤数据1)服务器需要安装Java，本测试使⽤java version “1.8.0_241”2)进⼊ServerAgent存放⽬录，使⽤命令“./”启动Agent3)需要确保端⼝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 测试策略测试策略编号10-1-1-1010-10-1-110-20-2-110-20-4-210-40-4-110-40-8-210-80-8-110-80-16-2。。。。。。并发数1010线程数110Ramp-up112448816循环101121212场景1个⽤户，每个⽤户每秒提交10次请求10个⽤户，每个⽤户每秒提交1次请求20个⽤户，每个⽤户2秒内提交1次请求20个⽤户，每个⽤户4秒内提交2次请求40个⽤户，每个⽤户4秒内提交1次请求40个⽤户，每个⽤户8秒内提交2次请求80个⽤户，每个⽤户8秒内提交1次请求80个⽤户，每个⽤户16秒内提交2次请求备注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）策略编号100-50-1-2100-100-1-1100-200-2-1100-1000-10-1100-1000-20-2样本1很卡⽆法测试平均值38324476850779最⼩值40413938最⼤值79358标准偏差294.89192.77716.6729633.03异常%0000.739吞吐量55.4368.6355.8712.17接收30.9638.3431.213.97发送30.9240.3733.037.35平均字节数572.00572.00572.00334.04评价稳定稳定稳定极差登录接⼝（线程池1000）策略编号100-1000-10-1样本1040平均值18037最⼩值43最⼤值30473标准偏差11904.87157异常%0.15吞吐量3.45接收1.77发送2.07平均字节数527.1评价差登录接⼝（线程池1500）策略编号100-1000-10-1样本1000平均值4189最⼩值32最⼤值13070标准偏差2803.22异常%0吞吐量54.38接收30.59发送33.06平均字节数576评价稳定登录接⼝（使⽤多个策略连续测试-线程池1500）策略编号1-10-10-110-100-10-1100-1000-10-1100-1000-10-1100-1000-10-1100-1000-10-11-10-10-11-10-10-14133657.94011.796.637.3858.243654.620021.6713.7712.197.7513.178.37576576⼀般⼀般1702803.22054.3830.5933.06576⼀般样本平均值最⼩值最⼤值标准偏差异常%吞吐量接收发送平均字节数评价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 获取接⼝此接⼝没有配置缓存拦截，数据直接读库获取⽤户（连续请求两次）策略编号样本平均值最⼩值最⼤值标准偏差异常%吞吐量接收发送平均字节数评价100-1000-10-1策略编号2000样本21平均值13最⼩值144最⼤值7.95标准偏差0.00异常%32.23吞吐量19.70接收19.67发送626平均字节数稳定评价各项测试策略表现的⾮常稳定3.1.4 编辑接⼝1)更新⽤户更新⽤户（连续请求两次）策略编号100-1000-10-1样本2000平均值7877最⼩值26最⼤值18932标准偏差4915.29异常%0吞吐量16.35接收4.17发送12.85平均字节数261评价稳定2)修改⽤户密码修改⽤户密码策略编号100-1000-10-1样本2000平均值3986最⼩值22最⼤值12778标准偏差2689.05异常%0.00吞吐量49.09接收12.80发送30.06平均字节数267评价稳定3.1.5 删除接⼝删除⽤户（暂时⽆并场景）策略编号样本平均值最⼩值最⼤值标准偏差异常%吞吐量接收发送平均字节数评价3.1.6 分页接⼝此处没有选择分页查看⽤户，是因为查询数据⽆数据，经排查是没有权限，但是搜索⾓⾊却可以。并且页⼤⼩为10，查询第⼀页没有考虑数据量⼤的情况，搜索⽐较靠后的页。此接⼝没有配置缓存拦截，数据直接读库分页查询⾓⾊策略编号100-1000-10-1样本2000平均值16最⼩值10最⼤值104标准偏差6.85异常%0.00吞吐量12.67接收25.41发送7.93平均字节数2054评价稳定3.1.7 其他接⼝⽤户服务编号123456…模块UserUserUserUserUserUser接⼝获得当前登录⽤户信息获得⽤户数据权限获得⽤户功能权限从数据库获取权限数据获得⽤户列表分页获取⽤户数据是否满⾜满⾜满⾜满⾜满⾜满⾜满⾜评价稳定稳定稳定普通稳定稳定获取同⼀个⽤户获取同⼀个⽤户获取同⼀个⽤户⽆权限备注⽐较突出的四个为评价“普通”，“⼀般”的。登录请求请看3.1.13.2 结果分析3.2.1 稳定性分析经过修复上⼀轮测试暴露出来的问题，⽬前登录、新增、编辑、查看、删除、分页等不同类型接⼝都有较好负载能⼒，满⾜团队当前对并发值100的期望值，部分接⼝平均响应时间未能满⾜要求，请求查看3.1。3.2.2 解决⽅案4 并发测试4.1 测试样本100-100-1-1策略下测试整个服务Label登录获得当前登录⽤户信息。。。# 样本1100平均值3331103最⼩值33352最⼤值3332379标准偏差0757.52异常 %0.00%0.00%吞吐量3.0033.17188接收 KB/sec1.6723.72发送 KB/sec0.91 5681.567656.2平均字节数Label总体# 样本4501平均值1303最⼩值52最⼤值3499标准偏差865.01异常 %0.00%吞吐量48.36561接收 KB/sec1987.8发送 KB/sec30.81平均字节数42085.8表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并发，循环持续执⾏。Label登录获得当前登录⽤户信息…总体26738797.880.50%10.406722425.96.61238703.3# 样本75600平均值2637511最⼩值137383最⼤值538729353标准偏差1393.34493.23异常 %0.00%0.00%吞吐量0.000380.24883接收 KB/sec0102.87发送 KB/sec00.12平均字节数568423337.8表3.3.1-1 汇总报告修改后 相同测试样本，Label登录。。。# 样本2平均值124最⼩值123最⼤值125标准偏差1异常 %0.00%吞吐量0.05811接收 KB/sec0.03发送 KB/sec0.02平均字节数568修改前和修改后服务器消耗资源对⽐图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-Memory5.1.2 创建接⼝类型可靠性测试1)创建⽤户Label登录创建⽤户总体# 样本13平均值478642194219最⼩值4263153153最⼤值51标准偏差294.541224.21224.16异常 %0.00%0.00%0.00%吞吐量0.00221.9478521.93116接收 KB/sec06.326.32发送 KB/sec014.6914.67平均字节数568295295表3.3.2-1 汇总报告修改后 平均响应时间缩短计算器60%，吞吐量增加300%Label登录创建⽤户总体# 样本11平均值44716091609最⼩值447177177最⼤值44757845784标准偏差0468.86468.88异常 %0.00%0.00%0.00%吞吐量2.2371461.7266461.70951接收 KB/sec1.2417.7817.78发送 KB/sec0.6841.3 29541.29295平均字节数568图3.3.2-1 服务器资源消耗-修改前后对⽐修改后：内存消耗稳定，且能够回收内存，之前需要运⾏1h23min，现在仅需27min，缩短67%的时间。图3.3.2-2 服务器资源消耗-Memory-对⽐2)创建功能Label登录创建功能接⼝总体# 样本21平均值487328292829最⼩值4512128128最⼤值523490219021标准偏差361910.88910.92异常 %0.00%0.00%0.00%吞吐量0.0028430.6369730.59851接收 KB/sec08.838.82发送 KB/sec023.4723.44平均字节数568295295表3.3.2-2-1 汇总报告修改后 平均响应时间缩短计算器57%，吞吐量增加270%Label登录创建功能接⼝总体# 样本21平均值4最⼩值375115115最⼤值44438423842标准偏差34.5432.26432.27异常 %0.00%0.00%0.00%吞吐量0.0173281.569281.54023接收 KB/sec0.0123.523.49发送 KB/sec0.0162.4862.45平均字节数568295295修改后：各项指标均运⾏平稳，其中内存消耗⽐较明显，之前需要运⾏58min，现在仅需20min，缩短65%的时间。图3.3.2-2-1 服务器资源消耗内存消耗⽐较：由于是单机部署，存在多个服务，此处只⽐较内存变化稳定性，修改后较修改前稳定。图3.3.2-2-2 服务器资源消耗-Memory5.1.3 编辑接⼝类型可靠性测试Label登录编辑⽤户# 样本5130000平均值42804761最⼩值416790最⼤值441530528标准偏差82.154445.93异常 %0.00%0.15%吞吐量0.0007617.24658接收 KB/sec04.4发送 KB/sec013.42平均字节数568261表3.3.3-1 汇总报告修改后 接⼝存在错误，并发下编辑同库同表同⾏数据，与本次测试的策略有关系。报错详情：This NpgsqlTransaction hascompleted;it is no longer usable. 限制因素：数据库⾏级锁限制或并发下事务处理⽅案需优化Label登录编辑⽤户# 样本434264平均值9288338最⼩值35284最⼤值230330455标准偏差805.267267.91异常 %0.00%0.59%吞吐量0.0013811.75666接收 KB/sec03发送 KB/sec09.15平均字节数568261.7服务器资源消耗对⽐图3.3.3-1 服务器资源消耗内存消耗对⽐：修改后编辑⽤户前期内存消耗正常，在程序后期出现错误后内存消耗严重，和本次测试策略有关系。图3.3.3-2 服务器资源消耗-Memory5.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结束之后调⽤e(buffer);清除Rpc过程中产⽣的垃圾。修改DotNetty服务端和客户端，涉及模块ty、tyWSServer、、、、。3)禁⽤Surging性能追踪组件。原因：使⽤微软DiagnosticListener组件，记录记录锚点数据⽤于记录性能追踪数据，BUP⽬前未启⽤surging的Skywalking（不完善），所以数据⼀直长留在内存中，4)集中式⽇志当不使⽤集中式⽇志时需要在配置中不启动5)未使⽤Module影响中Packages->Using配置：ServiceProxyModule、SkywalkingModule6)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-测试接⼝列表编号 服务名 接⼝名 接⼝URL1 ⽤户 登录 POST /api/user/login?servicekey=User2 获得当前登录⽤户信息 GET /api/user/getcurrentuserinfo?servicekey=User3 创建⽤户 POST /api/user/createuserinfo?servicekey=User详细请翻阅附件2-测试脚本附录2-测试脚本JMeter打开··已删除jmx⽂件··PostMan打开··已删除 postman_··附录3-数据库数据统计原始测试数据库是从253已存库备份⽽来1.数据库编号 数据库⼤⼩测试项 bup_xxx_stability bup_cap_stability bup_yyy_stability1 测试前数据 15 MB 8157 kB 15 MB2 负载测试 15 MB 8245 kB 20 MB3 并发测试 15 MB 8789 kB 23 MB4 可靠性测试 26 MB 31 MB 57 MB2.数据库表⼤⼩编号 数据库 表名 原始 负载测试 并发测试 可靠性测试1 bup_basedata_stability hed 16 kB 16 kB 16 kB 16 kB。。3.数据库表⾏数编号 数据库 表名 原始 负载测试 并发测试 可靠性测试1 bup_basedata_stability Xxx_t_xxxx 348 348 348 348…