《网络压力测试报告.pdf》由会员分享,可在线阅读,更多相关《网络压力测试报告.pdf(10页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、压力测试报告1. 引言21.1 编写目的 21.2 系统概述 21.2.1 项目名称21.2.2 总体目标21.2.3 技术目标22. 测试环境 22.1 软硬件环境 22.1.1 网络拓扑结构 32.4 测试环境约束33. 测试范畴及测试要求3.1 测试33.1.1 测试内容33.1.2 测试通过标准 34. 测试工具 35. 测试结果 36.1 测试时刻及人员 36.2 测试结果分析46. 结论103引言1.1 编写目的本文档是对(项目名称)性能测试所做的讲明, 为充分利用已有的软硬件资源,配合对各系统应用模块的运行测试方案,查缺补漏完善系统的各项具体功能,保证项目的顺利进行,本测试报告有
2、助于实现以下目标:明确此次性能测试的测试资源;明确此次性能测试的测试内容;明确此次性能测试的测试方法;明确此次性能测试的系统性能。1.2 系统概述1.2.1 项目名称项目名称: 小象工程项目简称: 小象工程项目单位: 扑像文化传播有限公司1.2.2 总体目标1.2.3 技术目标1.2.3.1 技术目标使用测试工具实现虚拟用户并发的压力测试,要求系统满足用户并发量在 100 以上,并能正常工作。测试环境2.1 软硬件环境硬件环境硬件配置应用服务器CPU 3.40GHzMemory: 2GHD: 360GSATAOS:Windows 2003JDK 1.5.0_06Tomcat 6数据库服务器CP
3、U 3.40GHzMemory: 2GHD: 360GSATAOS:Windows 2003MySQL 5.0.17 Linux客户端CPU 2.20GHzMemory: 2GHD: 360GSATAWindow xpProfessional( SP3 )软件配置2.1.1 网络拓扑结构2.4 测试环境约束此次测试结果依据目前被测系统的软/硬件环境。此次测试结果依据目前被测系统的程序版本。此次测试结果依据目前被测系统的网络环境。此次测试结果依据目前被测系统的测试数据量。测试范畴及测试要求3.1 测试3.1.1 测试内容按照需求,对登录操作进行并发的压力测试,对要紧业务模块中的要紧业务(下点单、
4、制作相册)进行压力和负载测试。3.1.2 测试通过标准系统在并发用户 100 时,系统表现稳固测试工具测试工具:Loadrunner8.0(美国 Mercury 公司)使用 Web(http/html)协议。要紧思想是使用虚拟用户(Virtual users)来模拟实际用户对系统施加压力。模拟图如下:测试结果6.1 测试时刻及人员时刻:2011.08.09人员:玲地点:深圳扑象文化传播有限公司6.2 测试结果分析LoadRunner 进行 100 用户场景模拟测试结果收集后,显示的该结果的一个摘要信息,如图5- 1 所示。概要中列出了场景执行情形、 “Statistics Summary(统计
5、信息摘要) ” 、 “Transaction Summary(事务摘要) ”以及“HTTP Responses Summary(HTTP 响应摘要) ”等。以简要的信息列出此次测试结果。图 5- 1 性能测试结果摘要图场景执行情形该部分给出了此次测试场景的名称、结果存放路径及场景的连续时刻,如图 5- 2 所示。从该图我们明白,此次测试从 16:17:08 开始,到 16:54:38终止,共历时 37 分 30 秒。图 5- 2 场景执行情形描述图Statistics Summary(统计信息摘要)该部分给出了场景执行终止后并发数、总吞吐量、平均每秒吞吐量、总要求数、平均每秒要求数的统计值,如
6、图5- 3 所示。从该图我们得知,此次测试运行的最大并发数为 200,总吞吐量为 960,974,180 字节,平均每秒的吞吐量为 426910 字节,总的要求数为117,105,平均每秒的要求为52.024。图 5- 3 统计信息摘要图Transaction Summary(事务摘要)该部分给出了场景执行终止后有关 Action 的平均响应时刻、通过率等情形,如图5- 4 所示。从该图我们得到每个Action 的平均响应时刻与业务成功率。图 5- 4 事务摘要图HTTP Responses Summary(HTTP 响应摘要)该部分显示在场景执行过程中,每次 HTTP 要求发出去的状态,是成
7、功依旧失败,都在那个地点体现,如图5- 5 所示。从图中能够看到,在此次测试过程中 LoadRunner 共模拟发出了 117105 次要求(与“统计信息摘要”中的“Total Hits”一致) ,其中“HTTP 200”的是 117105次,讲明在此次过程中,通过发出的要求全部分都能正确响应了( “HTTP 200”表示要求被正确响应) 。图 5- 5 HTTP 响应摘要并发数分析“Running Vusers(运行的并发数) ”显示了在场景执行过程中并发数的执行情形。它们显示 Vuser的状态、完成脚本的 Vuser的数量以及集合统计信息, 将这些图与事务图结合使用能够确定 Vuser的数
8、量对事务响应时刻产生的阻碍。图 5- 6 显示了在系统业务性能测试过程中 Vusers运行情形,从图中我们能够看到,Vusers的运行趋势与我们场景执行打算中的设置是一样,表明在场景执行过程中,Vusers是按照我们预期的设置运行的,没有 Vuser显现运行错误,如此从另一个侧面讲明我们的参数化设置是正确的,因为使用唯独数进行参数化设置,如果设置不正确,将会导致Vuser运行错误。ColorColorScaleScale1MeasurementMeasurementRunGraph Min.Graph Min.0.0Graph Ave.Graph Ave.105.1Graph Max.Grap
9、h Max.200Graph MedianGraph Median129Graph SDGraph SD78.219图 5- 6 运行的并发数图我们此次测试 Running Vusers与集合点是一致,讲明整个场景执行过程中,并发数用户的执行正确,系统测试服务器能够应对200 个并发用户的业务操作。响应时刻“Average Transaction Response Time(平均事务响应时刻图) ” (图 5-7) ,这张图是平均事务响应时刻与结果摘要中的“Transaction Summary”合成的。ColorColorScaleScale11111MeasurementMeasureme
10、ntlogin_Action_Transactionselect_allAction_Transactionselect_oneAction_Transactionvuser_end_Transactionvuser_init_TransactionMin.Min.0.4528.71924.4840.00.001Ave.Ave.47.11526.64893.9830.0110.05Max.Max.109.38144.704329.9741.2970.418SDSD30.25711.23139.9330.0970.095图 5- 7 平均事务响应时刻图从图形下部我们能够看到,登录部分对应的Act
11、ion 是“login_Action” ,批量查询对应的 Action 是“select_allAction” ,选择信息查询对应的 Action是“select_oneAction” ,他们的“Average Time(平均响应时刻为) ”分不是47.115 秒与 26.648 秒与 93.983 秒,从这三个数值来看,都过大,不符合要求。实际事物时刻应为登录: 47.115/5 5 = 4.423 (减 5 登录时包含了一个用户信息查询)批量查询:26.648 /5 = 5.3296选择信息查询:93.983 /5/7 = 2.685 (除 7 做了 7 次点击选择信息)注:除 5 所有的
12、事物都被重复执行 5 次看完了“Average Time” ,我们再看“90 Percent Time” ,表示 90%的事务登录: 95.711/5 5 = 14.142(减 5 登录时包含了一个用户信息查询)批量查询:39.125/5 = 7.825选择信息查询:146.797 /5/7 = 4.194 (除 7 做了 7 次点击选择信息)注:除 5 所有的事物都被重复执行 5 次从图 5- 7 能够看出,所有 Action 平均事务响应时刻的趋势有较大的波动,因此使用“90 Percent Time” 。按照上面的运算,此次测试结果记录如表 5- 1 所示。测试项实际值是否通过YYY登录
13、业务响应时刻14.142 秒批量查询响应时刻7.825 秒选择信息响应时刻4.194 秒登录业务成功率考勤业务成功率登录查询总数批量查询总数选择信息总数CPU 使用率内存使用率100%100%100010001000坚持 100%20%表 5- 1 测试结果对比表一每秒点击数图 5- 8 显示的是“Hits per Second”与“Average Throughput (bytes/second)”的复合图,从图中能够看出,两种图形的曲线都正常同时差不多一致,讲明服务器能及时的同意客户端的要求,并能够返回结果。图 5- 8 每秒点击数与每秒吞吐量复合图业务成功率。在“Transaction
14、Summary”中我们能够专门明确的看到每个事务的执行状态,如图 5- 9 所示。ColorColorScaleScale1MeasurementMeasurementPass图 5- 9 事务状态统计图从图中能够看出,所有的 Aciton 差不多上绿色的,即表示为 Passed,同时除了 vuser_init 与 vuser_end 两个事务,其他的事务通过数为 2163,也就表明在 30 分钟的时刻里,共完成了 2163 次登录考勤业务操作。那么按照这些能够判定此次测试登录业务与考勤业务的成功率是100%,再次更新测试结果记录表如表 5- 2 所示。测试项实际值是否通过登录业务响应时刻14
15、.142 秒Y批量查询响应时刻7.825 秒选择信息响应时刻4.194 秒登录业务成功率考勤业务成功率登录查询总数批量查询总数选择信息总数CPU 使用率内存使用率100%100%100010001000YYYYYYY表 5- 2 测试结果对比表二系统资源系统资源图显示了在场景执行过程中被监控的机器系统资源使用情形,一样情形下监控机器的 CPU、内存、网络、磁盘等各个方面。此次测试监控的是测试服务器的CPU 使用率与内存使用率, 以及处理器队列长度,具体的数据如图 5- 10 所示。ColorColorScaleScaleMeasurementMeasurementMin.Min.Ave.Ave
16、.Max.Max.SDSD10.110% Processor Time (Processor _Total):192.168.0.108Available MBytes (Memory):192.168.0.108Processor Queue Length (System):192.168.0.1084.1674860.063.813500.5961.96291.406570317.08113.5363.204图 5- 10 测试服务器系统资源监控结果图从图中能够看出,CPU 使用率、内存使用率、CPU 的队列长度三个指标的曲线逗较为平滑,三者的平均值分不为:63.813 %、500.596
17、、1.962,按照此次性能测试要求的:CPU 使用率不超过 75%,内存使用为 130M。按照 Windwos资源性能指标的讲明,一样情形下,如果“Processor Queue Length(处理器队列长度) ”一直超过二,则可能表示处理器堵塞,我们那个地点监控出来的数值是 1.962 接近 2, 而且总体上保持平稳, 那么由此推断,测试服务器的 CPU 也可能是个瓶颈。获得上述数据后,最新的测试结果记录表如表5- 3 所示。测试项实际值是否通过登录业务响应时刻14.142 秒Y批量查询响应时刻7.825 秒选择信息响应时刻4.194 秒登录业务成功率考勤业务成功率登录查询总数批量查询总数选
18、择信息总数CPU 使用率内存使用率100%100%10001000100063.813 %130MYYYYYYY表 5- 3 测试结果对比表三从上表数据来看,此次测试总体上差不多达到了预期的性能指标,但从其他的数据,例如 CPU 的队列长度、内存使用率来看,被测服务器的硬件资源需要提升。通过 tomcat 检测工具 probe ,内存使用 130M。结论测试中,系统在大量用户使用和长时刻反复运行中,系统未显现不良反应,包括cpu、内存占用过高、内存泄露等,系统反应良好,在大吞吐量情形系统响应时刻令人中意,系统稳固性比较可靠。另:测试 250 到 300 用户的情形下系统表现情形。结果发觉系统在 250 以上显现连接超时等现象,故在此次测试环境下并发用户峰值在250。