财通证券UF20证券集中交易业务系统压力测试方案V11.docx
《财通证券UF20证券集中交易业务系统压力测试方案V11.docx》由会员分享，可在线阅读，更多相关《财通证券UF20证券集中交易业务系统压力测试方案V11.docx（19页珍藏版）》请在冰豆网上搜索。
财通证券UF20证券集中交易业务系统压力测试方案V11
ProjectDocumentation
财通证券UF20证券集中交易业务系统
压力测试方案
经纪业务运营平台V2.0
2014年09月
修订记录
版本
修订人
修改说明
修改日期
**
柯俊
文档创建
2014-10-10
**.网络结构图4
**.逻辑部署图4
**.设备及应用软件4
**.单用户单请求测试6
**.日间常用功能混合效率10
**.查持仓压力测试11
**.查成交压力测试12
**.综合场景连续发包测试13
1.测试目的
本次压力测试主要通过专业级负载测试工具Loadrunner，模拟新一代集中交易系统（UF2.0）日常主要的业务功能，对集中交易系统的中间件（AR、LS、AS）、数据库以及网络情况做一个负载及稳定性方面的测试，以评估全系统的性能与稳定性。
评估的目标主要包含以下几个方面：
一、查找影响系统稳定性的风险点：
通过设置常见故障场景，查看系统是否出现处理异常或性能急剧下降等情况；
二、评估系统单笔处理耗时，找出系统优化环节：
在一定系统压力下，通过分析常见业务功能各环节的耗时时间，系统可优化环节；
三、评估系统的有效并发处理能力：
在常用业务功能单笔平均处理耗时均未超过日常平均处理耗时130%的情况下，系统每秒处理的总业务请求数是否能达到期望值。
2.测试范围和内容
测试地点：
浙江省杭州市滨盛路2000号联通大厦4楼
测试时间：
2014-09-20
测试人员（财通）：
测试人员（恒生）：
柯俊、林景忠、涂青、瞿小龙
测试场景：
单业务多客户并发与混合业务多客户并发测试
测试脚本：
常见周边业务功能如下（9月16日06版统计结果）
06功能号
功能号描述
请求数占比
UF20功能号
UF20功能名称
200
服务_周边_客户登录
**
331100
客户登陆
300
服务_周边_委托股票
**
333000
代码输入确认
407
服务_周边_取帐号信息
**
331300
证券股东信息查询
301
服务_周边_委托价格
**
333001
大约可买获取
402
服务_周边_取客户当前成交
**
333102
证券成交查询
401
服务_周边_取委托流水
**
333101
证券委托查询
302
服务_周边_委托确认
**
333002
普通委托
405
服务_周边_取客户当前资金
**
332255
客户资金精确查询
403
服务_周边_查股票
**
333104
证券持仓查询
需要增加的周边历史查询功能
06功能号
功能号描述
请求数占比
UF20功能号
UF20功能名称
308
服务_周边_普通交割
339300
历史交割查询
412
服务_周边_取历史资金证券流水
339305
历史资金证券流水查询
411
服务_周边_取历史成交
339304
历史证券成交查询
421
服务_周边_取历史委托
339303
历史证券委托查询
以现有生产数据为样本，随机获取客户账号，录制脚本，根据测试方案设置每类业务的并发用户数和发送频度；
测试均采用业务功能混合模式
根据财通实际情况结合恒生压力测试推荐设计的测试流程
1.单业务多客户并发性能测试
Ø测试功能号
测试功能号
测试功能名称
备注
331100
客户登陆校验
数据样本：
10万（上海深圳各5W）
333002
普通委托
数据样本：
10万（上海深圳各5W）
333101
查委托
数据样本：
10万（上海深圳各5W）
333104
查持仓
数据样本：
10万（上海深圳各5W）
332255
查资金
数据样本：
10万（上海深圳各5W）
339303
查历史委托
数据样本：
10万（上海深圳各5W）
339300
查历史交割
数据样本：
10万（上海深圳各5W）
Ø测试方法
通过LoadRunner连接P1_AR_JAR1的T2端口19019，根据录制好的案例脚本及多客户数据样本分别进行各功能的压力测试，观察各机器资源消耗情况并记录各测试结果。
2.混合业务多客户并发性能测试
Ø测试功能号
测试功能号
测试功能名称
配比建议
备注
331100
客户登陆校验
**
数据样本：
10万（上海深圳各5W）
333002
普通委托
**
数据样本：
10万（上海深圳各5W）
333101
查委托
**
数据样本：
10万（上海深圳各5W）
333104
查持仓
**
数据样本：
10万（上海深圳各5W）
332255
查资金
**
数据样本：
10万（上海深圳各5W）
339303
查历史委托
0----------40
数据样本：
10万（上海深圳各5W）
339300
查历史交割
0----------40
数据样本：
10万（上海深圳各5W）
Ø测试方法
通过LoadRunner连接P1_AR_JAR1的T2端口19019根据功能号配置比将录制
好的案例脚本及多客户数据样本进行压力测试，观察各机器资源消耗情况并记录各测试结果。
3.测试数据强度
测试数据见如下：
测试功能号
测试功能名称
备注
331100
客户登陆校验
数据样本：
10万
333002
普通委托
数据样本：
10万
333101
查委托
数据样本：
10万
333104
查持仓
数据样本：
10万
332255
查资金
数据样本：
10万
339303
查历史委托
数据样本：
10万
339300
查历史交割
数据样本：
10万
4.测试环境说明
概要：
财通证券UF2.0准生产环境，数据库设备使用的三台小型机（IBM780*2+IBM750*1），中间件设备使用的HP380；数据库的逻辑部署情况：
一个交易中心，一个经营管理中心；
系统环境：
后台数据库：
交易中心（RAC）+经营管理中心
中间件部署：
（硬件配置、线程数等）
数据环境：
当前生产数据，一年以上的历史数据；
4.1.网络结构图
4.2.逻辑部署图
略
4.3.设备及应用软件
机器型号
配置
数量
用途/要求
HDSVSP
G1000
32*300GB15KSAS硬盘
（交易）
24*300GB15KSAS硬盘
（归档、同步文件系统）
1
主交易存储：
每8块盘做1个RAID10的RAID组
操作系统对lun做条带化（stripesize为512K）
IBMP780
CPU：
24*4.2GHz（Power7+）
内存：
128G
网卡：
4x1000M
2
交易服务器（ORACLERAC）
AIX版本为6100-06-10-1241
hacmp版本为6.1
HDSHUS150
8*200GBSSD硬盘
（交易）
6*200GBSSD硬盘（历史索引）
32*300GBSAS15K硬盘（历史数据、归档数据、同步软件、归档目录）
1
经营管理存储：
8块SSD盘做RAID10
6块SSD盘做RAID5，
SAS盘，每7块盘做1个RAID5的RAID组
操作系统对lun做条带化（stripesize为512K）
IBMP750
CPU：
32*4.0GHz（Power7+）
内存：
128G
网卡：
4x1000M
2
经营管理服务器（ORACLERAC）
AIX版本为6100-06-10-1241
hacmp版本为6.1
HPDL380
CPU：
2*4核2.4GHz
内存：
8G
网卡：
1000M
硬盘：
2*146GB带电池阵列卡
14
逻辑AS
RedhatLINUX5.5。
HPDL380
CPU：
2*4核2.4GHz
内存：
8G
网卡：
1000M
硬盘：
2*146GB带电池阵列卡
4-19
原子AS
RedhatLINUX5.5。
HPDL380
CPU：
2*4核2.4GHz
内存：
8G
网卡：
1000M
硬盘：
2*146GB带电池阵列卡
14
AR/BAR
RedhatLINUX5.5。
HPDL380
CPU：
2*4核2.4GHz
内存：
8G
网卡：
1000M
硬盘：
2*146GB带电池阵列卡
2
申报回报服务器
模拟成交
安装windows2003server。
HPDL380
CPU：
2*4核2.4GHz
内存：
8G
网卡：
1000M
硬盘：
2*146GB带电池阵列卡
6
原子处理&路由转发
安装linuxredhatAS4U8。
HPDL380
CPU：
2*4核2.4GHz
内存：
8G
网卡：
1000M
硬盘：
2*146GB带电池阵列卡
2-4
LoadRunner11
柜台客户端
5.财通压力测试场景
由于系统环境较为庞大不易观察所有机器的资源消耗情况，测试时应先分析每个业
务经过的路由涉及中间件及机器再重点关注。
通过对财通证券单业务多客户并发测试，达到检测系统平台的在单项业务情况下，最多能达到多少业务交易笔数、响应时间的初值，找出现有业务系统部署方式，整个业务系统的性能瓶颈。
为后续的优化部署提供数据基础。
财通要求：
在无系统压力情况下，获取各常见业务功能单笔平均处理耗时
5.1.单用户单请求测试
测试情况记录
单用户单请求委托，验证单笔请求的最高效率
场景描述
功能号
单笔请求耗时（ms）
平均每秒请求处理数量（笔）
备注
单用户单委托请求，连续发包
333002
20
50
较平稳
单用户单客户登录请求，连续发包
331100
29
36
较平稳
单用户单查委托请求，连续发包
333101
7
135
较平稳
单用户单查持仓请求，连续发包
333104
17~24
40~60
有振幅
单用户单查资金请求，连续发包
332255
22
45
较平稳
单用户单查历史交割请求，连续发包
339300
15
65
较平稳
单用户单查历史委托请求，连续发包
339303
22
45
有振幅
测试截图（单笔单用户委托情况.）：
测试截图（单用户登陆连续）
测试截图（单用户查委托）：
测试截图（单用户查持仓）：
测试截图（单用户查资金）：
测试截图（单用户查历史交割）：
测试截图（单用户查历史委托）
5.2.日间常用功能混合效率
测试情况记录
场景描述
功能号（配比）
单笔请求耗时（ms）
平均每秒请求处理数量（笔）
备注
客户登陆校验
331100（300）
29
300
普通委托
333002（200）
22
200
查委托
333101（300）
7
300
查成交
333102（300）
20
300
查持仓
333104（500）
20
500
查资金
332255（500）
45
500
查历史委托
339303（100）
25
100
查历史交割
339300（100）
17
100
测试截图：
场景总结：
1、发包频率为1秒一个请求，因此多少用户就是该请求每秒的发包数
2、该压力下，系统运行很平稳，数据库压力较小
3、中间件压力也较小，主要压力在cuser,ctrade,call上，但是也在5%-15%之间
5.3.查持仓压力测试
场景总结：
查持仓时对AS_CUSER的压力较大，达到25%的利用率
AS_CTRADE和AS_CALL的压力在10%左右
效率达到5000笔/秒，平均耗时0.1秒
测试截图:
5.4.查成交压力测试
场景总结：
1、单成交300用户连续发包会导致loadrunner机器顶到100%利用率；
2、分3个机器分别加压100用户，CPU利用主要在AS_CUSER,AS_CTRADE,AS_CALL,LS_CALL上
3、利用率最高达到近70%（AS_CTRADE,AS_CALL），AS_CUSER到50%，LS_CALL到33%
4、随着AS_CUSER处理机器的增加，处理包数从9000-12000-14000
5、查询效率在100用户到200用户时，从平均0.11ms-0.18ms；但是在AS_CUSER增加个数时，查询效率又从0.18ms下降到0.14ms
测试截图：
5.5.综合场景连续发包测试
测试情况记录
场景描述
功能号（配比）
单笔请求耗时（ms）
备注
客户登陆校验
331100（29）
50
普通委托
333002（19）
45
查委托
333101（28）
14
查成交
333102（9）
40
查持仓
333104（48）
38
查资金
332255（48）
50
查历史委托
339303（10）
42
查历史交割
339300（9）
34
场景总结：
每个配比的周边功能都连续发包，三组loadrunner加压，最高处理笔数14000笔左右，瓶颈在AS_CUSER,AS_CTRADE,AS_CALL上
现有中间件配置能支持每秒14000笔请求，其中委托占比9%，约1200笔/秒，平均每笔委托耗时在40ms左右，是无压力下委托效率的两倍
测试截图：
6.测试总结
经过压力测试验证，系统各日常周边功能运行正常，能够满足正常压力和极限压力情况下的系统并发量要求和客户端响应要求。
中间件对日常周边功能的压力瓶颈主要体现在as_cuser、as_ctrade、ls_call三组节点上，但是均可以通过线性增加节点数量解决系统瓶颈情况。
升级会员 