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

(原创文章,转载请注明出处。)

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

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

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

据此,我们可以做如下尝试:

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

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

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

二、软硬件环境配置

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

在实际测试过程中,需关注以下问题:

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

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

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

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

三、性能监控指标定义

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

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

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

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

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

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

时间: 2024-08-11 04:28:09

交易系统升级之性能测试思路的相关文章

再谈性能测试之需求调研

之前的博客聊聊性能测试开始前的准备工作,聊了一些关于性能测试开始前要做的准备工作.这篇博客,来谈谈性能测试开始前的需求调研阶段,我们要做什么,关注那些Point... 一.基本信息 信息类型 说明 项目名称 项目归属的业务线,项目名称 项目类型 新建.迭代.重构... 项目背景 因为什么原因,需要进行性能测试 测试目的 进行性能测试的目的:容量规划.性能验证或者其他原因 测试范围 被测系统业务模块,属于什么业务,有什么特点 里程碑 设立此次性能测试的里程碑,即不同阶段的达成以什么为结束标志,比如

深度解析容器化技术在广发证券交易系统的应用【转】

原文链接:http://geek.csdn.net/news/detail/94850 本文是docker落地比较好的实践案例,文中很多地方多可以学习一下,以下是摘录: 为什么要容器化 对传统的垂直行业来讲,Docker也是最近几年才出来的技术,技术理念非常先进,因此采用Docker容器化技术对我们而言需要综合的评估,但是我们为什么要去做呢?首先,从行业现状来说,证券行业一方面量化交易.高频交易.实时风控要求高,其次,行业创新非常多,创新业务也很频繁,另外,监管方面,证监会证监局对我们要求交易事

最实用的现货白银交易系统

成功的操盘手离不开一套成功的交易系统,完善的日交交易系统应该包括以下要素: 1 .开仓法. 日内交易有着时间短.见效快的特点,因此开仓与趋势交易有着很大的区别,趋势操作使用倒金字塔加码法和平均加码法比较好,而日内操作应在快和准为原则上采取试仓法和一次建仓法. “ 试仓法” 适用于信号准确率不太高(低于 90% )的操作,先用 5% 的仓位进行试探,如果发展一段时间止损位不破,基本趋势没有被打破的迹象,并且价格基本上还处于成本区时可在评估风险的基础上加仓,此法能有效规避看盘失误而引起的较大损失,而

Web下的整体测试 --性能测试及优化思路

随着Internet的日益普及,现在基于B/S结构的大型应用越来越多,可如何对这些应用进行测试成为日益迫切的问题.有许多测试人员来信问我B/S的测试如何做,由于工作较繁忙,对大家提出的问题也是头痛医头脚痛医脚,没有对WEB的测试过程做一个整体的概述.希望通过本篇能够让大家了解大型Web应用是如何来进行测试的. B/S下的功能测试比较简单,关键是如何做好性能测试.目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了,为了证明而去测试是没有任何价值的,关键是要发现产品性能上

移动客户端系统升级思路

移动客户端系统升级思路                        下载:升级思路+1.0版本效果图 一.设计思路: 1.升级程序和主程序分开,每次先启动主程序,在主程序中点击升级,退出主程序,启动升级程序,由升级程序来检测是否有新版本需要升级:(考虑是否要在,检测到有新版本后再退出主程序) 2.如果有更新的话,则由升级程序将服务器上的更新文件下载回本地,如果升级程序自身也有更新的话,则把新的升级程序重命名下载保存在本地: 3.所有更新文件下载完毕或者没有新版本的话,升级程序启动主程序,同时退

从0到1简易区块链开发手册V0.4-实现转账交易的思路分析

六.转账交易 创世区块创建完毕之后,按照我们的正常思路,是继续创建新的区块,并加入至区块链中,没错,这确实是学习路线,但是我们首先来了解一个区块是如何生成的,转账交易 ===>打包交易 ===>工作量证明 ===>生成区块 在上文,我们提到了钱包地址这个概念,我们一般可以简单将钱包地址理解为一个银行账户,那么交易也就可以理解为是地址与地址之间的转账过程. 因为这部分内容非常重要,设置可以说交易就是比特币原理的核心,所以,为了保证大家对概念有充分的了解,本章节的理论描述部分此处摘录liuc

性能测试-服务端瓶颈分析思路

概述 性能测试中,对服务端的指标监控也是很重要的一个环节.通过对各项服务器性能指标的监控分析,可以定位到性能瓶颈. 后端性能指标有CPU,内存,网络,I/O等等 分析思路 整体系统CPU利用率 内存利用率 磁盘I/O的利用率和延迟 网络利用率 CPU定位分析 CPU利用率大于50%,需要注意:大于70%,需要密切关注:高于90%,情况比较严重. 监控命令:vmstat.sar.dstat.mpstat.top.ps 类型 度量方法 衡量标准 利用率 1.vmstat 统计1-%idle 2.sa

性能测试培训思路

定义: 是指在某个特定的硬件.软件.网络环境下通过自动化的测试工具模拟多种正常.峰值以及异常负载条件来对系统的各项性能指标进行测试. 含:执行效率,资源占用,稳定性,安全性(压力测试是安全测试的一种),兼容性(class文件能不能放到兼容性平台上,如程序和浏览器内核能不能弄到一起去) loadrunner 工作原理 --来源于性能测试面试问题 性能测试实施步骤 loadrunner的脚本工作 性能测试的目的 验证改进的性能效果,需要和以前的测试结果进行比对: 新的业务上线,验证新系统能够满足系统

性能测试方案设计的方法和思路

第一步获取性能需求   需求一:用户数信息 1)调查系统当前和未来使用的用户数 系统用户数=本系统目前注册的用户数,注册用户数并不代表他会每天并且无时无刻的使用着. 在线用户数=同时在线对系统进行操作的用户数量(相当于混合场景) 并发用户数=同时在线并且同时操作同一个功能(单场景添加集合点) 估算未来一到五年使用此用户的数量,可以根据一些日志数据估算出来的. 2)调查系统当前和未来的每日.月活跃用户数 当前活跃用户数,即某天大概有多少用户使用本系统:那么这部分数据一说来也就是当前真正对系统构成压