文档详情

运营内控压力测试方案

nu****n
实名认证
店铺
DOC
829.51KB
约31页
文档ID:157774164
运营内控压力测试方案_第1页
1/31

浦发银行运营内控系统性能测试方案浦发运营内控项目组2007年11月目 录1 术语与解释 32 测试目的 43 测试工具说明 54 测试用例选取 64.1 选取用户操作 64.2 选取测试用例 74.3 确定性能衡量指标 85 准备测试环境 115.1 生产环境说明 115.1 测试环境说明 126 测试结果及分析 146.1 测试用例一:单独执行任务查询时的各项性能指标 146.2 测试用例二:单独执行后督交易查询时的各项性能指标 146.3 测试用例三:三项操作混合执行的压力测试 156.4 测试用例四:正常压力下三项操作混合执行的稳定性操作 156.5 测试用例五:高压力下三项操作混合执行的稳定性操作 167 附录 177.1 测试脚本说明 177.2 测试数据源说明 177.3 测试程序修改说明 171 术语与解释术 语解 释性能测试(performance testing)通常指负载测试、压力测试和稳定性测试的集合通过运行这些测试来确定系统的各项性能指标以及瓶颈所在性能测试的通常指标包括相应时间、吞吐量和系统资源使用率负载测试(load testing)用于衡量系统在特定负责情况下的运行状态,以及各项性能指标。

压力测试(stress testing)用于衡量系统在计划外的压力情况下的各种行为,帮助分析系统在什么请看下会故障,以及故障的表现和症状稳定性测试(reliability testing)持续进行的性能测试,以确定应用系统稳定性和品均故障间隔时间(MTBF)并发访问(Concurrent Request)指在同一秒钟内同时向系统发起服务请求吞吐量(Throughput)指在单位时间(一般是1小时或1分钟)内系统能完成完整业务的数量响应时间(Response Time)指从用户向系统发起一笔服务请求开始至系统给予应答所花费的时间2 测试目的为了确运营内控系统的顺利上线,在系统上线运行之前解决系统开发中可能存在的各类问题,包括:Ø 性能指标:通过负载测试(在一个场景下特定的并发用户以特定的间隔发起请求)确定系统的相应时间和吞吐量,以确定性能指标在用户接受的范围之内Ø 系统资源使用情况及Bug和瓶颈所在:通过压力测试(主要通过增加用户并发量)测得系统在负载过大和资源不足情况下的表现,由此找到影响整个系统的资源瓶颈所在,从而对程序进行优化或对系统资源进行调整Ø 系统长时间运行的稳定性:通过在通常业务负荷量下的长时间(一至两天)运行系统,观察系统的故障和资源使用情况,发现类似于内存泄漏等程序问题。

3 测试工具说明本测试使用微软的Visual Studio Team System 2005集成开发工具以及Visual Studio 2005 Team Test Load Agent负载模拟工具Ø Visual Studio 2005 Team System 是一个可扩展的生命周期工具集成套件,能带来更高的工作效率它对 Visual Studio 产品线进行了扩展,帮助软件开发团队更好地交流与协作此外,Visual Studio 2005 Team System引入了一组测试工具,这些工具集成在 Visual Studio 环境中,可帮助构建高质量的应用程序Ø Visual Studio 2005 Team Test Load Agent用于生成补充测试负载它与 Visual Studio 2005 Team Edition for Software Testers 结合使用后,可以允许组织模拟更多的用户,以及更精确地测试 Web 应用程序和服务器的性能通过以上工具的结合,可以灵活的制作测试单元脚本,并将一个或多个单元脚本依照设定的发生比率和用户并发数对服务器进行测试此外,Load Agent还允许讲多个客户端机器组成测试集群,并通过一台控制节点统一测试行为。

4 测试用例选取4.1 选取用户操作根据对运营内控系统的业务量和并发分析,结合系统的结构特性,在本方案中选用以用户操作:Ø 任务查询:所有登录到系统的用户客户端,会通过自动轮询的方式查看当前的任务事项n 用户量计算:根据业务规划,该操作涉及的用户数目为900人(200个总分行后督岗+700个分支行差错岗)根据测试环境的等比缩小,在性能测试中设定的用户数为450人按照最大并发量20%的经验值推算,其并发请求数为90人/秒n 请求间隔计算:1秒Ø 后督交易查询:模拟后督岗位的用户最频繁的查询操作n 用户量计算:涉及的操作用户为200人,根据等比缩小,在性能测试中设定用户数为100人按照最大并发量20%的经验值推算,其并发请求数为20人/秒n 请求间隔计算:根据业务部门估算,每个用户处理一条后督任务的最快、最慢和平均时间分别为1分钟、10分钟和3分钟根据OPM算法,其平均处理时间为230秒钟((O+P+4M)/6)n 详细操作:测试脚本将采用数据源绑定的方式,模拟每次后督任务的常规操作细节及其之间的操作间隔备注:由于方式一和方式二的操作对系统而言完全相同,因此只选择其中的一种进行模拟非集中业务的后督操作相对发生很少,因此在性能测试中可以忽略。

Ø 差错登记操作:指在后督作业中对发现的各类差错进行登记业务对差错的估算为最高不超过5%,每条处理时间为10分钟因此,登记差错操作与后督交易查询操作的比率为1:774.2 选取测试用例针对以上的操作,在本次测试中共设计以下测试用例:性能测试:Ø 测试用例一:单独执行任务查询时的各项性能指标n 测试方法:用户数为90人测试三次取平均值,每次持续运行时间为30分钟TBDn 结果衡量:获得每个请求的最小、最大和平均响应时间;并关注和记录系统各项资源指标的负荷情况是否在预警阀值之内Ø 测试用例二:单独执行后督交易查询时的各项性能指标n 测试方法:用户数为20人测试三次取平均值,每次持续运行时间为30分钟TBDn 结果衡量:获得每个请求的最小、最大和平均响应时间;并关注和记录系统各项资源指标的负荷情况是否在预警阀值之内压力测试:Ø 测试用例三:三项操作混合执行的压力测试n 测试条件:同时模拟任务查询、后督查询以代表系统最频繁的操作(其他操作从符合角度任务是可以忽略的)其初始的用户数和相应时间与性能测试中等同,随后每10分钟增加0.5倍用户量增长幅度是否合理,直到某项观测指标达到并超过阀值,系统进入无法响应的状态。

n 结果衡量:系统的瓶颈资源所在;在达到瓶颈时系统能支持的最大用户数量及相应的响应时间此时可能需要关注Request Timeout的比率稳定性测试:Ø 测试用例四:正常压力下三项操作混合执行的稳定性操作n 测试条件:以正常的压力同时模拟任务查询、后督查询以代表系统最频繁的操作并持续运行24小时n 结果衡量:系统资源占用率及变化趋势;在此状态下系统的吞吐量;同时观察服务器网卡流量,以确定系统上线后对生产网段的流量影响Ø 测试用例五:高压力下三项操作混合执行的稳定性操作n 测试条件:以较高压力(压力测试中达到阀值的并发量)同时模拟任务查询、后督查询以代表系统最频繁的操作并持续运行24小时n 结果衡量:系统资源占用率及变化趋势4.3 确定性能衡量指标根据以上的测试用例,确定各类测试相应的衡量指标其主要包括:性能指标:根据运营内控系统特性,主要相关的性能指标为用户响应时间、系统吞吐量系统资源指标,包括:网络和应用服务器序号对象计数器说明系统指标1MemoryAvailable MBytes是计算机上可用于运行处理的有效物理内存的千字节数量,是通常意义上的物理可用内存2Processor% Processor Time指处理器用来执行非闲置线程时间的百分比,是通常意义上的CPU使用率3Network Interface5Bytes Total/sec是在每个网络适配器上发送和接收字节的速率,包括帧字符在内,是通常意义上的网络吞吐量ASP.NET指标2ASP.NETRequest Wait Time这个指标就是响应时间吗?队列中最近一次请求等待处理的毫秒数。

3ASP.NETRequest Queued队列中等待服务的请求的数目当该数开始随客户端负载的增多而线性增加时,Web 服务器计算机已达到能同时处理的请求数的上限该数的默认最大值为 5,000可以在 Machine.config 文件中更改此设置4ASP.NETRequest Rejected由于服务器资源不足无法处理请求而未能执行的请求的总数该计数器表示返回 503 HTTP 状态代码(指示服务器太忙)的请求的数目5ASP.NET ApplicationRequests/Sec每秒钟执行的请求数目代表系统当前的吞吐量在特定的负载下,改数据应该保持在固定范围内Failed request?? Throughput?数据库服务器系统指标1MemoryAvailable MBytes是计算机上可用于运行处理的有效物理内存的千字节数量,是通常意义上的物理可用内存2Processor% Processor Time指处理器用来执行非闲置线程时间的百分比,是通常意义上的CPU使用率3Physical DiskAvg.Disk ytes/Read在读取操作时从磁盘上传送的字节平均数,是通常意义上的读磁盘4Physical DiskAvg. Disk Bytes/Write在写入操作时从磁盘上传送的字节平均数,是通常意义上的写磁盘5Network Interface5Bytes Total/sec是在每个网络适配器上发送和接收字节的速率,包括帧字符在内,是通常意义上的网络吞吐量SQL指标1MemoryTotalServerMemory(KB)服务器当前占用的动态内存总量2LocksNumberof Deadlocks/sec导致死锁的锁请求数3Buffer MemoryBuffer cache hit ratio数据库Cache的命中情况4GeneralUser Connections数据库的连接数量5 准备测试环境5.1 生产环境说明根据设计方案,运营内控系统的生产环境采用两层结构,其拓扑结构如下所示:其各项服务器配置如下:服务器型号配置概述数量备注网络及应用服务器 PC Server 4 x Dual Core CPU 8GB内存2x144G硬盘(采用RAID1)2 采用NLB集群数据库服务器PC Server 4 x Dual Core CPU 8GB内存2x144G硬盘(采用RAID1)2 采用Cluster集群存储设备SAN磁盘阵列1.3TB(2008年估算)3.7TB (2011年估算) 1 5.1 测试环境说明测试环境拓扑如下:其配置采用等比缩小原理,使用与生产环境1:2的比例进行配置。

其服务器的配置为:服务器型号配置概述数量备注测试用网络及应用服务器 PC Server 4 x Dual Core CPU 8GB内存2x144G硬盘(采用RAID1)2 采用NLB集群测试用数据库服务器PC Server 2 x Dual Core CPU 8GB内存2x144G硬盘(采用RAID1)2 采用Cluster集群此外,影响测试结果的额外差别包括:Ø 存储机制生产环境采用SAN共享磁盘存放数据库数据,其处理效果优于本地磁盘因此,当数据库服务器的磁盘IO成为瓶颈时,需要重新评估测试结果Ø Session同步损耗由于生产环境采用NLB的网络服务器部署,需要通过Session State技术对用户Session进行同步,并由此带来相应的性能损耗为了模拟并发用户请求,测试中将使用多台客户端采用虚拟用户的方式客户端的配置情况如下:服务器型号配置概述数量备注负载代理控制节点PC1 x Dual Core CPU 2GB内存80G硬盘1统一管理所有的负载代理节点,以协调各自的工作负荷和并发负载代理节点PC1 x Dual Core CPU 1GB内存80G硬盘5各节点配置略有差异由于客户端的配置和性能各异,为了避免由于客户端负载过大造成对测试结果的影像,在测试中应关注客户端的系统资源指标,并在总符合不变的前台下调整各节点的负荷,以将各自负载控制在合理范围内。

6 测试结果及分析6.1 测试用例二:单独执行后督交易查询时的各项性能指标Ø 请求相应时间Note: each transaction is composed of multiple (avg. 20) requests. Ø 应用服务器系统资源指标Ø 数据库服务器系统资源指标6.2 测试用例一:单独执行任务查询时的各项性能指标Ø 测试结果Ø 请求相应时间Ø 应用服务器系统资源指标Ø 数据库服务器系统资源指标Ø 分析说明6.3 测试用例三:Add MistakeØ 测试结果n 请求相应时间n 应用服务器系统资源指标n 数据库服务器系统资源指标Ø 分析说明Ø6.4 测试用例三:三项操作混合执行的压力测试Ø 测试结果n 请求相应时间n 应用服务器系统资源指标n 数据库服务器系统资源指标Ø 分析说明6.5 测试用例四:正常压力下三项操作混合执行的稳定性操作(actually 2)Ø 测试结果n 请求相应时间n 0.76 for AuditProcessn 0.064 for GetTask (no write in process)n 应用服务器系统资源指标n 数据库服务器系统资源指标Ø 分析说明6.6 测试用例五:高压力下三项操作混合执行的稳定性操作Ø 测试结果n 请求相应时间n 应用服务器系统资源指标n 数据库服务器系统资源指标Ø 分析说明7 附录7.1 测试脚本说明针对测试用例中选取的脚本,使用Visual Studio Team System 2005集成开发环境分别进行录制,以制作成测试的基础单元。

再通过对基础单元的行为配置和组合,制作成相应的压力测试、负载测试和稳定性测试脚本,以在测试环境中运行7.2 测试数据源说明采用录制脚本进行测试可能存在的问题是:无法真是模拟不同用户的不同查询为了避免数据库讲查询结果进行缓存导致的测试结果不可参考,在测试中讲采用数据源绑定的方式通过预先准备模拟生产环境的数据源,并将其绑定到测试脚本中,以使得每个虚拟用户的访问都查询不同的业务记录7.3 测试程序修改说明为了配合测试,并使测试的结果更有效,需要对系统做相应的修改,包括取消用户登录界面等其修改的前提是不对测试的结果产生影响Second time get task performance test。

下载提示
相关文档
正为您匹配相似的精品文档