各位好，我叫王捷豪，在测试行业已经有 7 年，曾从事过酒店、空气质量、电网领域，目前是国内某互联网医疗公司研发中心基础平台部一名测试开发工程师，多年的测试工作对测试知识有一些小认识，希望通过该篇文章与各位分享关于如何开展不同测试类型的性能测试，以及性能测试环节中遇到的一些问题与解决方案。本次性能测试是针对集成服务开展的一系列性能测试，其中性能测试范围包括基准测试、配置&定容定量测试。
1.什么是集成服务
集成服务（Integration Services）是用于生成高性能数据集成和工作流，包括针对数据源数据的提取、转换和加载等操作的解决方案，主要解决众多系统情况下，不同系统之间点对点通信需要开发新接口问题。因此，通过搭建统一规范、统一代码、统一接口的信息集成平台，以集成服务为中介，实现各系统间的信息共享和交互。
2.集成方案介绍
下图是基于集成服务部署的一个数据同步集成方案，该集成方案通过获取数据源数据，并按照映射关系转化数据，同步至目标数据库，集成方案具体操作有以下几点：
通过日志轮询 JDBC 连接数据库，按照设定的时间间隔，定时查询任务日志表多条日志数据，返回日志数据所关联的业务数据
通过分支节点修改发送次数，记录操作次数，当操作次数超出 3 次，日志仍处于同步失败状态，则不再同步该条日志的业务数据
通过映射处理器转换数据，并保存数据至目标数据库，同时修改日志表日志状态为成功
3.集成服务架构图
在性能测试过程中，了解服务的系统架构图能够更清楚性能压力在哪个环节上，如在集成服务同步数据过程中，可以对数据库、集成服务、中间件、日志服务器等节点进行监控。
4.如何选择压测工具
在开展性能测试前，通常情况下需要选择性能测试工具对接口进行多并发施压，如主流的性能工具 LoadRunner、JMeter，但实际上压测对象不一定是可见的接口。对于本次分享的集成服务，其原理是通过设置的定时器按照最快秒级频率触发一次同步任务，其压力不在接口并发数量上，而是在调度频率、同步数据量大小上，因此无法借助性能工具进行压测。
5.基准测试
基准测试（benchmarking）是在某个时间点通过基准测试建立一个已知的性能水平线（称为基准线），当系统的软硬件环境发生变化之后，通过再次基准测试建立新基准线，对新旧基准线进行比较，以确定哪些变化对性能的影响。
5.1 工作开展过程
在进行基准测试前，需制定相应测试计划，确定测试目的、测试范围、测试环境、集成方案、测试准备内容、测试用例等内容。
在测试范围上，挑选了两个业务场景（见下方表格），其中注册场景，其视图关联表数据复杂程度低；而登记场景，其视图关联表数据复杂程度相对注册场景高，且关联表字段有 BLOB 类型字段，该字段可以存储二进制文件。这两个场景的区别在查询一条数据时，数据大小和关联复杂程度。
在部署测试集成方案时，通过和现场开发人员、产品经理多次确认生产实际部署方案，目的是为了尽可能贴近现场方案。由于性能测试开展在现场部署之前，最终测试集成方案（见下方第一张图）和生产集成方案上存在一定区别（见下方第二张图），这与前期评估不够精准以及现场人员对业务需求进一步了解后发生的变更有关系。
在测试准备内容方面，除了部署集成方案，需按照场景分别制造测试数据，了解表与表之间的关联关系，此次批量制造日志表 1w 条数据，视图表数据 10w 至 20w 数据。
#批量制造数据SQL
BEGIN
for i in 1 .. 100000 loop
#插入SQL
INSERT INTO INSERT INTO "库名"."表名" (字段名,关联id字段名) VALUES ('字段值', i);
end loop;
commit;
END;
在基准测试用例方面，挑选了调度频率、日志轮询查询条数、数据大小、日志表数据量、视图表数据量五个变量进行测试，通过五个变量采集同步数据总耗时、每秒可同步条数、实际调度频率结果，最终找出最佳方案设置下最佳基准线。同时，对每个变量设定中值线（下表调度频率变量 3 秒每次），在中值线基础上设置下限值（下表调度频率变量 1 秒每次）和上限制（下表调度频率变量 5 秒每次），其中中值线通过和现场开发人员、产品经理沟通确定，测试过程中会发现确定的中值线不一定准确，因此需要额外场景测试找到中值线。
5.2 问题和解决方案
- 问题 1：制造 10w 数据的时候，插入数据失败，提示 unable to extend lob segment by 128 xxxx in tablespace xxxx
解决方案：找 DBA 增加表空间
- 问题 2：基准测试开展前，由于集成方案保存数据接口通过其它产品线开发人员配置，因此需要产品线和产品线之间开发人员的配合，但实际还面临其它产品线开发人员去了现场或是有其它紧急任务，导致基准测试进度无法推进
解决方案：创建一个性能测试专项群，把产品经理、开发人员、测试人员拉进去，通过产品经理推动性能测试进度，同时根据任务优先级安排时间和工作，如开发人员现场任务紧急，测试人员可以准备测数据以及设计测试用例等其它工作
- 问题 3：采集结果波动大，如上方表格场景编号 1-1 测试用例，1w 条日志同步完总耗时可能偏差 10 多秒，是因为测试环境不只是一个用户使用，而且部署了非当前性能测试其它服务
解决方案：最好的方式是部署独立的测试环境，但实际上部署成本高以及设备资源少，只能协调或避开测试环境多用户使用高峰期，或者对场景进行多次采集，剔除异常数据之后求均值
-
问题 4：集成方案调度任务状态出现长时间处于执行中，或是集成服务出现崩溃，由于集成服务内存分配了 512M，而 JDBC 节点查询数据时主要消耗内存资源，导致 JVM 频繁 GC
解决方案：集成服务调整内存分配至 1G，同时限制 JDBC 节点查询数据量以及降低调度频率
6.配置&定容定量测试
配置测试：通过对被测试软件的软硬件配置进行测试，找到系统各项资源的最优分配原则。配置测试能充分利用有限的软硬件资源，发挥系统的最佳处理能力，同时可以将其与其它性能测试类型联合应用，从而为系统提供重要依据。
定容定量测试：在一定的软硬件条件下，在数据库中构造不同数量级的记录数量，通过运行一种或多种业务场景在一定虚拟用户数量的情况下，获取不同数量级别的性能指标，从而得到在该数量级下系统能够处理的最大会话能力、最大容量等。
6.1 工作开展过程
与基准测试 5.1 工作开展过程不同的是，配置&定容定量测试调整了场景用例和增加了监控。
在测试用例设计上，选择了注册场景、更新场景作为相同场景，用于测试多节点场景。另选择登记场景作为定容定量场景，通过更改 BLOB 文件大小控制数据量级。
在选择性能监控平台上，数据库监控通过 Grafana 平台，主机监控由于公司没有统一的监控平台，因此主机监控通过多个平台配合监控，包括 Grafana、VMware vSphere、linux 命令、Spring Boot Admin。
在开始配置测试前，由于需要更改 CPU、内存、磁盘等资源，因此需要运维工程师协助驱散集成服务所在节点，禁止别的容器调度节点，同时需要系统工程师协助调整主机 CPU 和磁盘资源大小，再由测试工程师自行重启集成服务，调整服务使用内存大小。由于启动集成服务至少需要内存 500M、磁盘 100G、CPU 4 核，否则较易出现服务崩溃或启动服务失败，因此以该配置做为最低配置。
在配置过程中，通过更改 CPU 核数发现，当 CPU4 核时，CPU 使用率 70% 左右。同时，CPU 核数对数据同步速度影响不大，每秒同步条数相差不大。
通过更改内存发现，当内存大小足以缓存低数量级数据时，内存大小对同步数据速度影响不大，每秒同步条数相差不大。
但当数据的数据量级发生变更，数据量级逐渐增大时，内存回收速度逐渐变快，一开始呈规律性回收（下方第一二张图），最后呈非规律性回收（下方第三张图）。
通过配置测试结果也可知，当数据量级增大时，内存消耗增大，集成服务同步速度下降。
6.2 问题和解决方案
- 问题 1：在配置测试过程中，再次出现采集数据波动较大，后来发现是数据保存接口所在服务器磁盘问题等待时间过长导致
解决方案：更换主机磁盘
- 问题 2：在测试过程中，出现磁盘不足，当前配置磁盘大小 100G，而日志会记录各个节点处理日志，包括打印出 SQL 查询的数据，并且没有定时清理日志
解决方案：日志只截取部分 SQL 查询出来的数据，减少日志内容，同时只保留固定天数日志，备份日志到其它磁盘空间
- 问题 3：在同步数据过程中，出现同步数据失败，后来发现是数据库缓存表不足导致，数据库关联查询数据或者排序时会使用到临时表
解决方案：增加临时表空间或者降低数据库操作频率，让缓存表数据能够有时间释放
7.个人感想
看过性能测试相关文章或者是开展过性能测试的小伙伴应该有体会， 性能测试不只是某一个人的事，也不只是测试部门的事，而是一个需要多角色人员参与和积极配合的性能团队。如果只有测试工程师一个角色人员或者其它角色人员不积极配合，性能测试工作都无法顺利推进。在本次性能测试过程中，参与进性能测试工作的角色包含了 DBA、运维开发工程师、系统工程师、测试工程师、开发工程师、产品经理、需求人员。同时，测试工程师在性能测试过程中，不只是对测试对象进行性能测试，更充当了协调配合和推进性能测试的角色。在专业技能上，测试工程师需要对系统架构、功能逻辑、性能知识、数据库、中间件等都有一定深度的认知，否则当性能问题出现时，无从下手，不仅无法定位或排查性能问题，也不知道如何让其它角色人员配合工作。
性能测试是一门很深的学问，需要不断积累，拥有扎实的基础知识，应当多学多问多实践。性能之路漫漫其修远兮，谨以此篇文章共勉在性能路上走得更远。