loadrunner项目性能测试分析报告.doc
性能测试报告xx版本xx项目性能测试报告1、基本信息Ø 测试性质：模拟正常用户使用情况下*版本*项目性能情况Ø 测试场景：计划查询，形象进度Ø 数据库业务量：按*公司目前的数据量来推算项目进度相关Table的数据量，且进行了60%增长率地翻倍动作Ø 系统总用户数：2400Ø 性能测试用户数：285 Ø 用户权限：非超级用户，但拥有系统管理员的权限Ø 测试系统： *版本*项目Ø 数据库服务器扩展内存AWE是否开启：未开启Ø 程序、数据库提供人： Ø 测试报告人： 彭玉红Ø 测试执行时间二八年十一月十一日Ø 报告时间 期工程二八年十一月十二日 Ø 目的：模拟用户的使用，找出*版本*项目使用过程中存在性能问题的点；2、 测试环境2.1服务器软硬环境：设备硬件配置软件配置IP 地址WEB CPU：2×4 DualCore Intel Xeon 5060 , 3.2 GHz（8核）内存：ECC,DRR2,8GB硬盘：Intel MegaSR SCSI 135GB/15000转 盘片平均延迟时间：2.0msWindows Server 2003 Enterprise SP2 IIS 6.024.5.2.249DB服务器CPU：2×4 QuadCore Intel Xeon E5335, 2.0GHz（8核）内存：ECC,DRR2,8GB硬盘：Ø Intel MegaSR SCSI 135GB/15000转（数据库主数据文件所在磁盘）Ø 500GB/7200转（日志文件所在磁盘）Windows Server 2003 Enterprise SP2 SQL Server 200544.5.2.154Web 负载客户端CPU：Intel(R) Pentium(R) D CPU 2.66GHz（双核）内存：1GB硬盘：迈拓160GB/7200转Windows Server 2003 Enterprise SP2IE6.0LoadRunner 8.03.5.4.712.2、网络环境：100Bytes局域网2.3、测试工具： LoadRunner 8.0 （此测试工具测试出来的事物响应时间为系统响应时间即：应用系统从请求发出开始到客户端接收到数据所消耗的时间）2.4、测试人员：测试脚本录制人：测试执行人： 3、 性能测试用例执行分析3.1、用例描述：计划查询用例事务点及动作描述说明：事务点方式事务性能点描述XMJD_001_JHCX_1_DK打开点击左侧关键节点计划导航标签XMJD_001_JHCX_1_XZST选择切换右上角视图到所有项目XMJD_001_JHCX_1_XZXM选择子项目在项目列表中选择一个具体的子项目(如:汇景新城"一期")形象进度用例事务点及动作描述说明：事务点方式事务性能点描述XMJD_002_LDXXJD_1_DK打开点击左侧楼栋形象进度导航标签XMJD_002_LDXXJD_1_XZLD选择楼栋选择具体的楼栋 （图一）3.2、场景加压方式（本分两种方式给脚本加压具体如下）加压方式脚本名称用户数用户迭代方式加压描述 系统压力情况方式一001_计划查询2251每分钟加载100个用户只承受来自于此脚本的压力方式一002_形象进度601运行时加载所有的用户只承受来自于此脚本的压力方式二001_计划查询+002_形象进度2851计划查询每分钟加载100个用户；形象进度加载所有用户承受两个脚本同时运行带来的压力注：用户计算方法见测试计划； （图二）4、 测试结果综合分析及建议4.1、优化建议计划查询各事务性能表现(备注表格中字段”参考值”来源于 0227版本总体业务需求总结.doc )事务点方式用户数业务笔数响应时间参考值说明事务性能点描述XMJD_001_JHCX_1_DK打开2251.8913秒性能良好点击左侧关键节点计划导航标签XMJD_001_JHCX_1_XZST选择2253.0283秒性能良好切换右上角视图到所有项目XMJD_001_JHCX_1_XZXM选择子项目2251.6063秒性能良好在项目列表中选择一个具体的子项目(如:汇景新城"一期")集团关键节点计划查询模块性能表现良好,但在脚本加压多用户并发时仍能侦测一些引起锁的SQL语句和存储过程为巩固此模块在*公司数据规模下的性能,故推荐对引起数据库相关共享锁的SQL语句及存储过程进行优化，具体语句及存储过程请见综合分析中给出的附档；形象进度各事务性能表现(备注表格中字段”参考值”来源于*版本总体业务需求总结.doc )事务点方式响应时间参考值说明事务性能点描述XMJD_002_LDXXJD_1_DK打开0.1233秒性能良好点击左侧楼栋形象进度导航标签XMJD_002_LDXXJD_1_XZLD选择楼栋34.5183秒需优化选择具体的楼栋 楼栋施工计划形象进度模块的性能瓶颈体现在程序和数据库两方面，其中尤以Table:jd_work 为首，该Table 频繁造成后端数据库的死锁，严重影响性能；程序方面页面：http:/10.5.2.249:9018/Xmjd/XXJD/LDJD_Main_BldXXJD.aspx?bldguid=d069f097-0d0e-4c52-8969-477bb364d55d&workguid=c8466b88-5751-4584-b402-3afd4010e0a7&graphtype=FenX的控件First Buffer Time 时间高达16 .137秒，应做优化； 4.2、综合分析计划查询模块性能分析：Transaction Summary Report （图三） （图四）（图三）即为脚本：001_计划查询按照（图二）中“方式一”来加压所产生的事物综合图表，通过此图表，我们可以看到各事物的性能表现均良好，响应时间处于用户可以接受的范围，后端WEB服务器，和数据库服务器中的各项主要性能指标均在正常值范围；（图四）即为脚本：001_计划查询按照（图二）中“方式二”来加压所产生的事物综合图表，我们可以看到当计划查询和形象进度两脚本一起给后端服务器施加压力时，因形象进度脚本的压力使后端数据库的CPU命用率长时间高达90%以上，进而使计划查询各事物的响应时间延长(三个事物的响应时间均超出用户能接受的范围)，且在计划查询脚本执行过程中仍侦测到由部分语句及存储过程引发的锁，具体如下附档，优化建议：附档中的语句过于复杂，考虑优化此语句及用存储过程的方式来实现；附档中的存储过程过于复杂，语句应优化，此语句中过多的使用局部临时表和游标，考虑用表变量的方式来替代，以提高性能；计划查询造成死锁SQL.Doc (注：以下附件没有附加，是因为考虑到公司数据的保密性J)计划查询造成死锁存储过程.Doc 形象进度性能分析：Transaction Summary Report （图五）（图五）即为脚本：002_形象进度按照（图二）中“方式一”来加压所产生的事物综合图表，从图表中我们可以看到事物：XMJD_002_LDXXJD_1_XZLD的90%事物响应时间均超过34.518秒，已超出用户所能接受范围。 （图六）（图六）即为平均事物响应时间，SQL Server CPU指标 及事物XMJD_002_LDXXJD_1_XZLD 的一个关联图，从图中我们可以看到整个形象进度脚本运行时长1分34秒，在脚本运行到40秒时，后端SQL Server的 CPU由原来的5%以下急升到95%以上,且维持到1分30秒，很明显此处已存在性能瓶颈，且事物：XMJD_002_LDXXJD_1_XZLD因CPU资源过度消耗，而造成在整个执行区间其执行时间一直在上升；此时分析后端WEB服务器的各主要指标发现均处于正常范围，初步推测在此情况下SQL CPU瓶颈即为后端SQL语句过度消耗CPU资源及其造成的死锁引发，所以重新运行一遍脚本，在整个过程中跟踪后端数据库中的死锁，发现在脚本运行到40秒时即已开始产生死锁，且一直到整个脚本运行结束后死锁才消除，时间与CPU出现急升的时间正好吻合，脚本运行期间频繁产生共享锁的SQL语句见以下的附档,另名为形象进度2008111201.trc的附档为脚本运行期间用Profiler跟踪出的所有与后台数据库服务器交互SQL语句,请针对耗用CPU资源明显的SQL语句做逐一的分析和优化. 形象进度造成死锁的SQL.Doc (注：以下附件没有附加，是因为考虑到公司数据的保密性J)具体优化建议为：1：定期对表 jd_work 重建索引，及碎片整理2：增加适当的索引，以提高查找效率3：优化相关的SQL语句4：表结构的重新设计，以从根本上解决或极大的降低死锁发生的频率为进一步分析造成事物XMJD_002_LDXXJD_1_XZLD高响应时间的性能问题是否与程序本身的页面组件或现实逻辑有关，我们通过LR对页面进行分解，发现此事物中的组件First Buffer Time 耗时为15.967秒，从此可看出我们的页面需进行性能优化，页面URL为：http:/10.5.2.249:9018/Xmjd/XXJD/LDJD_Main_BldXXJD.aspx?bldguid=d069f097-0d0e-4c52-8969-477bb364d55d&workguid=c8466b88-5751-4584-b402-3afd4010e0a7&graphtype=FenX具体见如下的（图七） (图七)备注：以上的分析素材来自LR分析文档: 1.申请_优化后_225user_100userMin_20081112_01.lra 2.形象进度展示_60user_60UserPerMin_20081112_01.lra 3.计划查询_225User_100UserPerMin_形象进度60user_60userMin_20081112_01.lra我看了你的报告！给你提如下的建议！1、因为任何性能测试过程中是存在风险的，一般报告中要有风险提示这个环节！你必须明确指出哪些做了哪些没有去操作2、我看了你的报告，第一感觉你的场景选择过少！一般一个系统不可能你选择这几个场景的3、你的模块选择过少4、我不知道你的场景运行时是当个场景运行出来的结果！还是综合出来的结果！5、性能测试报告在开始之后要有一个比较肯定的总结性结果！是通过了性能测试还是没有通过。一般写报告先有结论！然后会有详细分析！我只看到你的分析！没有看到你的结论！以上一些粗粗的建议！供你参考！呵呵！呵呵,谢谢非常感谢admin能给我这么多好的建议,因为目前公司就我一个人在做性能测试,所以过程中遇到的一些问题,或是有哪些地方做的不足的都没个人可以讨论一下的,深感郁闷呀,所以真的非常感谢大家在这里据我的分析报告提出的一些中肯的建议. 以下为对admin提出的建议我的一些回答:1:模块太少答:我的这份测试报告是一份分批次进行测试的性能分析报告(为更好地配合开发的时间安排及提高测试的效率,所以我把性能测试分为三个批次进行,每个批次分两轮(性能优化前和优化后的论证),此贴附加的为第一批次的第一轮测试报告-所以只有两个模块,后续在第二批次和第三批次的性能测试中会进行相关业务模块的单模块测试和日常操作组合模块的性能测试.2:报告中没有一个明确的测试结果我在报告中已经有给出应该是在第4大点的第4.1小点中,是以表格加初略的分析来说明的-请您看下这种方式您看合适吗?3:在测试报告中没有风险分析的说明非常好的建议,我会考虑加进去,但是我应该在风险分析中说明一些什么呢再次感谢风险报告一般包含：环境的局限性、测试内容的局限性、测试时间等 第 7 页 共 7 页
