金牛项目性能测试报告

1、1 / 19文档可自由编辑打印产品名称Product Name密级Confidentiality Level金牛公安分局视频资源管理系统 秘密产品版本Product Version1.00共11页针对金牛公安分局视频资源管理系统稳定性及最大并发数问题性能测试报告 (仅供内部使用)拟制:赵枫日期：2012-12-14审核:日期：审核:日期：批准:日期：2 / 19文档可自由编辑打印修订记录日期日期修订版修订版本本描述描述作者作者3 / 19文档可自由编辑打印目录1测试设计测试设计 .41.1对象分析.41.2测试策略.41.3测试模型.51.3.1测试环境描述.51.4详细测试方法.51.4.1

2、测试方法综述.51.4.2并发用户计算及启动.61.4.3业务模型.61.5RUNNING VUSERS(运行虚拟用户图表分析) .71.6RENDEZVOUS(集合点图表分析).71.7AVERAGE TRANSACTION RESPONSE TIME(平均事物响应时间图表分析).81.8HITS PER SECOND & AVERAGE THROUGHPUT(页面每秒点击率和平均吞吐量合并图表分析).91.9TRANSACTION SUMMARY(事物总体估计图表分析).91.10PAGE DOWNLOAD TIME BREAKDOWN(页面下载崩溃时间段图表分析) .101.11

3、TIME TO FIRST BUFFER BREAKDOWN(第一次缓冲时间细分图表分析) .101.12WEB PAGE DIAGNOSTICS(WEB页面诊断图表分析).111.12.1LogInPageVisist页面(首页页面访问) .111.12.2LogInPageVisist页面(首页页面访问) .131.12.3LogOut (注销功能操作).141.12.4EntrycaseRecordPage(进入案件信息录入页面).141.12.5caseInformationSubmit (案件信息提交动作).151.13CPU使用情况(测试结果) .161.14各个功能模块ACTIO

4、N事物成功率总结.172测试结论测试结论 .183测试风险测试风险 .204 / 19文档可自由编辑打印金牛项目（针对系统稳定性和最大并发数问题）性能测试报告关键词：关键词： 金牛公安分局视频资源管理系统 性能测试 事务响应时间 每秒事务数 测试报告摘摘 要：要：本测试报告用于说明金牛公安分局视频资源管理系统的最大并发数以及稳定性的测试结果。缩略语清单：缩略语清单： 金牛公安分局视频资源管理系统金牛公安分局视频资源管理系统概述概述本测试报告用于说明金牛公安分局视频资源管理系统稳定性(最大并发数)压力测试结果。1 测试设计测试设计1.1对象分析系统按照B/S（Browser/Server）模式设

5、计。用JSP实现前台，ORACLE10G 做后台数据库。Web服务器使用Tomcat6.0.2 ，编译器使用JDK1.6.0_20版本，WEB服务器日志输出调整为ERROR级。1.2测试策略本次测试分别模拟50个用户，虚拟50个IP，进行系统首页登录、案件管理功能中案件信息上传等操作，持续运行时间范围为(0.6个小时到2.4个小时)。1.3测试模型1.3.1 测试环境描述1. 2.3.1.1 测试环境需求a)系统环境标准配置:主机用途机型/OS台CPU/内存对应IP5 / 19文档可自由编辑打印数台容量/台Web服务器Windows 2008 Server1116G192.168.0.111数

6、据库服务器Windows 2008 Server1116G192.168.0.111测试代理服务器Windows XP114G192.168.0.42b)测试工具要求:PC 1台(为实际情况考虑应考虑使用多台个人PC来实现不同PC不同IP的负载均衡功能)，LOADRUNNER 11.0 性能测试工具。c)测试代码要求:准备好测试数据，系统资源，开启web服务。TOMCAT配置java内存为最小500M，最大 1000M。1.4详细测试方法1.4.1 测试方法综述根据金牛公安分局视频资源管理系统中的权限管理机制，理想情况同一IP只能同时登录一个用户(但实际情况同一IP可以允许多个用户登录)，这样

7、模拟多个用户就需要多个不同的IP，否则权限系统会拒绝登录，无法模拟实际的情况，故采用IP欺诈的方法，虚拟出50个不同的IP进行测试。根据项目经理的要求，选取金牛公安分局视频资源管理系统中的关键业务点：系统首页登录、案件管理等模块，分别模拟50个IP，50个用户，100个用户，100个IP，持续的运行0.6个小时至2.4个小时的测试场景。测试在这样的压力下，系统是否会崩溃。1.4.2 并发用户计算及启动第一次测试模拟50个用户，同时启动系统首页登录、案件信息上传操作。监视统计数据：根据性能测试的目的，主要对WEB服务器的CPU、内存、进行监控和分析。因测试服务器与测试代理机在同一网段内，故忽略网

8、络因素。本次测试没有监控数据库资源使用情况。下表列出了主要需监控的选项。监控计数点描述WEB服务器6 / 19文档可自由编辑打印CPU 测试过程中CPU的使用率内存测试过程中内存使用率1.4.3 业务模型业务流程如下：OA系统：1、使用用户帐号登录（用户名username使用参数化随机取值，密码根据用户名关联参数化）登陆到。(首页登录)2、选择“案件管理”按钮，点击“信息录入”选项；(案件管理)3、脚本里实现对案件相关(案件名称，案发地址，天网点位号)信息的参数化，图片信息(CaseID,ImageName)的参数化。实现对案件信息的随机信息录入并提交执行功能以及图片的随机上传功能。1.5Ru

9、nning Vusers(运行虚拟用户图表分析) 从0分0秒到8分的时候用户数逐级增加(每1分钟增加4个用户，增加到50个),从2小时08分，用户数逐级减少(每1分钟减少4个用户)，此处的Vuser表现不正常(所有用户集合的时间提前了)。7 / 19文档可自由编辑打印1.6Rendezvous(集合点图表分析)集合点图表明It满足场景集合点设置策略(即100%的用户到达集合点及12.5分钟后场景继续执行)1.7Average Transaction Response Time(平均事物响应时间图表分析)（这个是比较关心的数据之一）a)时间越小说明处理的速度越快，如果和前面的用户负载生成图合并在

10、一起看，就可以发现用户负载增加对系统事务响应时间的影响规律（事务的响应时间也不应该超过用户的最大接受范围，否则会出现系统响应过慢的问题）。b)除了案件信息录入(CaseInformationRecordIn)包括了：案件信息提交操作(CaseInfomationSubmit)，点击进入案件信息录入页面(EntryCaseRecordPage)。8 / 19文档可自由编辑打印以及登陆登出事物时间耗时比较长，其他的事物表现均比较稳定。我们可以看到，登录(login)的操作，平均响应时间为75.785s，这个已经是除去think time的数值；对于首页访问(LogInPageVisit)，平均响应

11、时间为74.656s，系统注销(LogOut)51.488s，案件信息录入(CaseInformationRecordIn)31.643s这4个响应时间超出预期目标设定(LoadRunner脚本回访的时候经常tomcat会报错:系统首页无法访问，要进行第二次回访才能继续，由此推断出系统首页访问可能存在问题，目前定位于有一定性能瓶颈)。1.8Hits per second & Average Throughput(页面每秒点击率和平均吞吐量合并图表分析)对于这个两个图来说，正常情况下他们的大致趋势应该是一样的，点击率反映client的请求情况，而吞吐量(Througput)则反映serv

12、er的响应情况。测试出的两个性能指标均已超出系统性能测试方案中设置的预期值(Hits per Second:1.851s)1.9Transaction Summary(事物总体估计图表分析)从图分析数据看以看出，每个功能模块脚本及场景执行的业务成功率均无限趋近于100%，满足系统性能测试方案中的预期设定值(业务成功率95%)9 / 19文档可自由编辑打印1.10 Page Download Time Breakdown(页面下载崩溃时间段图表分析)我们可以看到红框标的地方，明显在VideoManagement和My97DatePicker.htm, indexc, (caseEntryPage

13、.jsp,URL=)这4个页面浪费了很多时间，基本都体现在First Buffer Time和Connection Time这两个计数器上(Measurement)。所以我们要对4个页面进行进一步的分析，我们来看First Buffer Time的分解图。1.11 Time to first buffer breakdown(第一次缓冲时间细分图表分析)我们从上图可以看出，主要是Server Time的问题，下面我们就要看看是Server哪些页面和组件出现了问题了。10 / 19文档可自由编辑打印1.12 Web Page Diagnostics(web页面诊断图表分析)1.12.1 LogI

14、nPageVisist页面(首页页面访问)1. Web页面诊断图分析。()2. 这个JS页面在页面下载时耗时很多。3.对于FirstBuffer里显示的资源消耗时间图相对来说要平稳的多。11 / 19文档可自由编辑打印等等。1.12.2 LogInPageVisist页面(首页页面访问)1.WEB页面诊断()12 / 19文档可自由编辑打印2.页面在页面下载时耗时很多 页面在页面下载时耗时很多13 / 19文档可自由编辑打印 3.这个页面的downloadTime耗时也比较多1.12.3 LogOut (注销功能操作)1.WEB页面诊断（）这个js这个js耗时长1.12.4 Entrycase

15、RecordPage(进入案件信息录入页面)耗时长。14 / 19文档可自由编辑打印1.12.5 caseInformationSubmit (案件信息提交动作)1.WEB页面诊断() 耗时多 15 / 19文档可自由编辑打印2. 耗时较多。从上面得几个图可以看出，ext-patch.css、login.css、joffice-gov2、ext-base.js、ext-all.css、ext-all.gzjs这6个页面耗费了很多的时间，全都是first buffer time，消耗在server上；这个6个地方需要开发人员进行检查，优化代码。1.13 CPU使用情况(测试结果)LoadRunn

16、er中100个虚拟用户在Run前进行准备时(Pending)时，任务管理器监视到此时CPU使用率达到了100%，说明CPU存在性能瓶颈(本机的)。16 / 19文档可自由编辑打印LoadRunner中100个虚拟用户刚开始并发运行回放脚本时，任务管理器监视到此时CPU使用率达到了100%，说明CPU存在性能瓶颈(本机的)。1.14 各个功能模块Action事物成功率总结每个模块Action的事务成功率都趋近于100%，说明脚本以及场景的设计符合用户实际业务处理情况。2 测试结论测试结论1. 预期结果17 / 19文档可自由编辑打印测试项业务时段响应时间90%响应时间业务成功率CPU 使用率吞吐

17、量(TPS)内存使用率首页访问1. 最大运行时间：24小时持续运行 2. 预计实际运行时间：3h 3. 场景相对运行时间:2.4h(2/8 原则计算出) 3 秒95%70%1.85170%登录模块1. 最大运行时间：24小时持续运行 2. 预计实际运行时间：3h 3. 场景相对运行时间:2.4h(2/8 原则计算出) 3 秒95%70%1.85170%案件信息录入1. 最大运行时间：24小时持续运行 2. 预计实际运行时间：3h 3. 场景相对运行时间:2.4h(2/8 原则计算出) 5 秒95%70%1.85195%Avg:10%0.1652.280G(57%)登录模块1. 最大运行时间：2

18、4小时持续运行 2. 预计实际运行时间：3h 3. 场景相对运行时间:2.4h(2/8 原则计算出) 8s8s95%Avg:10%0.1652.280G(57%)案件信息录入1. 最大运行时间：24小时持续运行 2. 预计实际运行时间：3h 3. 场景相对运行时间:2.4h(2/8 原则计算出) 5s5s95%Avg:10%0.1652.280G(57%)a)因为各个模块有失败的事物，造成了的事物执行没有 100%成功，但是是达到预期指标的；同18 / 19文档可自由编辑打印时首页访问，登录模块，案件信息录入的平均事物响应时间也超过了预期的 3s。待开发人员进行性能调优。b)另外经过分析：1.2.3.4.5.6.7.这 7 个相关页面代码(js,htm,jsp,action)需要开发人员协助帮忙看一下，因为他们 7 个文件耗费了不少时间和资源，需要调优。c)待开发人员优化完毕后，经过冒烟测试通过，在进行一次性能测试。d)其他一些相关问题:本次测试共执行2次，第一次执行2.4小时(50Vusers)，第二次执行0.6小时(100Vusers)。1、通过分解测试对象的相关页面，发现几个主要操作，涉及到数据库查询，添加的操作，在服务器端的耗时比较长，体现在登陆，案件管理中的信息录入，注销这几个模块上。故推测出以上模块的sql语句可能存在