交易系统升级之性能测试思路

Posted 2020-10-13

（原创文章，转载请注明出处。）

      随着资本市场活跃度的提升，A股行情日趋火爆。越来越多的互联网企业、私募机构参与其中。为满足投资者财富管理并为其提供更为便捷的金融服务的需要，核心交易系统重构成为提升机构服务能力的重要方式。交易系统性能是体现互联网证券业务能力的重要指标，如何确保新构建的交易系统能够满足针对互联网大数据量的业务需求成为重中之重。因此必须对交易系统的性能容量指标进行合理的评测，以满足经营机构中长期业务发展的需要。本文将从建模策略和数据采集、软硬件环境配置及性能监控指标定义等方面提出相关测试思路。抛砖引玉，以求更进一步的理解。

      一、建模策略和数据采集：

      性能测试往往面临如下问题：一、业务模型单一，且与线上实际业务偏差比较大；二、数据脱离实际。

      据此，我们可以做如下尝试：

      在建模策略方面，根据证券类交易系统的特点，事前，确定了两套业务场景实施方案，日常业务场景与高峰业务场景，分别应用于不同的测试类型。同时，依次分析线上各事务的重要程度、发生频率、变化规律及发展趋势，形成单业务场景、多业务场景、多业务综合场景等不同的备选集合。在实际实施过程中，运用顶层规则，在备选集合中，选取占比较大的业务纳入业务模型。并参考线上业务实际发生过程，进行最终业务模型确认。

      在数据采集方面，由于系统存在线上运行记录，运用线上历史运行数据分析的方式，提取数个典型交易日的数据样本，细化分析交易量、交易发生时间、发生分布及变化率，形成业务模型的数据来源。首先，对于日常业务场景，以年度数据为基础，以月为单位，采集各年的业务增长量，比较各年中月业务的变化量，形成数据。其次，对于高峰业务场景，以日交易变化为基础，以5-10分钟为单位，分业务采集各个不同业务的业务量及业务数据。时间间隔越短，所采集的数据量越准确。最后，在实际测试过程中，以以上分析为基础，尽可能的将数据生成过程参数化，以便快速形成单套基础测试数据、多套业务测试数据。

      在测试执行策略与方法的选择上，我们制定了如下测试类型的实施策略：基准测试、单场景测试、混合场景并发测试、容量测试、浪涌测试及稳定性测试。其中，针对不同阶段的上线过程，还需要贯穿部分配置测试。

 

      二、软硬件环境配置

      交易系统的重构很大一部分是软硬件的更新换代。机构在与供应商的对话中常常处于弱势地位。供应商相对集中，对机构比较强势。通常在提供给机构其软硬件资源后，仅做简单的技术支持，能满足基本要求即可，而对系统优化需求的支持较弱，使得机构无法客观、真实、有效的了解其软硬件设备更新所带来的实际收益。由此，需要通过单模块、单节点、多模块、多节点、配置测试等性能测试的方式，排查系统软硬件瓶颈，并进一步找到系统的最优配置，真正了解系统软硬件的功效。还可以逐步扩展并覆盖到软硬件选型、容量规划、性能评估验收、性能优化等领域。

      在实际测试过程中，需关注以下问题：

      第一，要保证硬件机型要一致。不同机型看似差异不大，但实际的表现却大有不同。例如数据库服务器，并非选取某厂商CPU核数高的最新产品，性能表现就越佳。对于多并发读写方式的数据库，往往CPU频率越高，它所表现的整体性能就越佳，而这款机型可能是该厂商往年的机型。

      第二，操作系统与软件版本要一致。这两者本身所表现出来的性能差异可能可以被预期或被忽略，但其与周边软硬件接口的性能变化却值得关注。例如新操作系统版本与旧数据库版本、或新数据库版本与旧存储所造成的性能表现变化。

      最后，拓扑结构要一致。测试环境可适当的采取低配的方式部署。例如，对于有多个负载均衡的部分，可缩小到一至两个，采取压力最大的负载均衡组。而对于一些可基本确定为非性能瓶颈的组件，可采用低配置部署。

      需要注意的是，测试过程中需与运维保障人员及时沟通，保证测试环境与生产环境参数类似。在此条件下，将关注点放在被测系统的硬件资源消耗上，排除软约束影响，分析性能瓶颈。

 

      三、性能监控指标定义

      根据交易系统的特点，在系统处理能力方面，需要纳入了TPS（Transaction Per Second）及业务端与数据库端的CPS（Call Per Second）；响应时间方面，配合不同的测试类型，需重点考察平均响应时间和最大、最小响应时间；并发用户数发面，在混合场景及浪涌测试中，需模拟多用户的并发操作；另外，事物成功率、资源利用率，包括CPU、内存、磁盘IO、网络带宽等一些基础指标均需要在最后的测试报告中有所体现。

      其次，需要做多轮次测试结果的比对。通过多轮次、在不同软硬件环境上的测试执行，配合系统硬件环境的微调及线上参数的最优配置，提供不同轮次间的比对结果。

      另外需要提一下的是，数据库端的并发操作往往会产生问题，需要从以下几个角度去思考：

      1. 委托处理中查询语句的使用频率。往往会存在大量的重复执行，建议可以考虑从应用程序层面进行优化。

      2. 反复执行的语句建议采用绑定变量的方式。

      3. 数据库的数据文件建议不需要开启自动增长；如果一定要开启，则不要配置成百分比增长，而是按照固定大小增长。