《LoadRunner压力测试结果分析探讨》由会员分享，可在线阅读，更多相关《LoadRunner压力测试结果分析探讨（10页珍藏版）》请在金锄头文库上搜索。
1、LoadRunner 压力测试结果分析探讨分析原则：1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）2. 查找瓶颈时按以下顺序，由易到难。服务器硬件瓶颈 网络瓶颈（对局域网，可以不考虑） 服务器操作系统瓶颈（参数配置） 中间件瓶颈（参数配置，数据库，web 服务器等） 应用瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）分析的信息来源：1. 根据场景运行过程中的错误提示信息2. 根据测试结果收集到的监控指标数据一错误提示分析分析实例：1Error: Failed to connect to server “172.17.7.230: 10060 Connec
2、tionError: timed out Error: Server “172.17.7.230 has shut down the connection prematurely分析：A、应用服务死掉。（小用户时：程序上的问题。程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题）B、应用服务没有死（应用服务参数设置问题）对应的 Apache 和 tomcat 的最大链接数需要修改，如果连接时收到connection refused 消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况和服务器硬件的情况来定，建议每次增加 25%！C、数据库的连接(数据库启动的最大连接数（
3、跟硬件的内存有关）)D、我们的应用程序 spring 控制的最大链接数太低2. Error: Page download timeout (120 seconds) has expired分析：A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大多D、实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境3. Error “http:/172.17.7.230/Home.do.”分析：A、脚本设计错误，造成页面异常。服务器有响应！B、并发数过大，造成服务器响应延迟。4. Error page “text=xxxxx”分析：A、脚本设计问题，例如，前
4、一脚本修改了某些内容，造成后面的脚本访问异常。B、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。只能反复修改脚本！二监控指标数据分析1Vusers 数Loadrunner 系统设置的虚拟用户数目。Vuser 去实际调用事先制作的脚本文件中的应用。每个 Vuser 产生响应的操作，所有的操作对服务器形成并发。颜色 比例 度量 图最小值 图平均值 图最大值 图中间值 图 SD1 Run 0.0 21.25 44 41 21.276在实际测试中，Vusers 可以根据实际情况的需要，在测试过程中增加或者减少。2最大并发用户数：颜色 比例 度量 最小值 平均值 最大值 SD100 A
5、pache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.0430.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.9240.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201应用系统在当前环境下能承受的最大并发用户数。在方案运行中，如果出现了大批用户的业务操作失败，或出现了服务器shutdown 的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用
6、户数。从上图可以看出：在测试运行到 4 个小时左右的时候，apache 的点击数/秒开始迅速增加！3业务操作响应时间：使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。颜色 比例 度量1 最小值1 平均值1 最大值分析事务的响应情况，要每次详细分析，目前还只能观察到响应时间过长的事务！4 每秒点击数负载测试期间每秒内 Vuser 在 Web 服务器上点击的次数。可根据点击次数来估算 Vuser 生成的负载数。颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图 SD1 点击次数 69.908 105.736 130.244 103.666 12.186从图中不难看出，在
7、4 小时的时候，点技数明显增高。和 apache 的每秒点击数增大的时间相吻合！5 吞吐量负载测试期间 Web 服务器上的吞吐量(字节)。吞吐量表示在任何指定秒内 Vuser 从服务器接收到的数据量。此图可估计 Vuser 生成的负载量(服务器吞吐量) 。颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图 SD1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473同样，从图中可以看出，在 4 个小时的时候，web 服务器的吞吐量开始增高。在图中还可以看到吞吐量的走势图，从开始到进行到 4 个小时反弹之
8、前呈降低的趋势，这是因为系统在初期调用的资源都是直接来之服务器，运行一段时间后系统的部分资源来自缓存。6 下载组件大小每个页面的组件大小，且包括组件的标头的大小！页面组件大小的分析表格比较复杂，实际分析中可以通过 loadrunner 的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件，如果其影响到了页面的下载速度，则要想办法将其改小！7 Apache 资源显示 APACHE web 服务器上的资源摘要。前面已经提到过以并发点击数为主。颜色 比例 度量 最小值 平均值 最大值 SD100 Apache CPU 使用情况 (Apache):172.17.7.210 0.777
9、0.852 0.93 0.0430.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.9240.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201三服务器资源监控指标：（目前通过 top 监察）内存：Linux 资源监控中指标内存页交换速率（ Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。实际测试中，当并发点击数出现突然剧增前后，内存的 PR 值则居高 25 不下。说明目前测试的系统中内
10、存存在瓶颈！内存资源成为系统性能的瓶颈的征兆:很高的换页率(high pageout rate);进程进入不活动状态;交换区所有磁盘的活动次数可高;可高的全局系统 CPU 利用率;内存不够出错(out of memory errors)处理器：Linux 资源监控中指标 CPU 占用率持续超过 80%（对该值的要求，根据具体应用和机器配置而要求不同，有资料表明 95），表明瓶颈是 CPU。实际测试中，当并发点技数出现突然增加前后，cpu 的占用率持续保持在 86以上！说明，目前系统用应用的 cpu 也是测试的瓶颈！CPU 资源成为系统性能的瓶颈的征兆:很慢的响应时间(slow response
11、 time)CPU 空闲时间为零(zero percent idle CPU)过高的用户占用 CPU 时间(high percent user CPU)过高的系统占用 CPU 时间(high percent system CPU)长时间的有很长的运行进程队列(large run queue size sustained over time)四数据库服务器：数据库服务器目前测试观察，当 web 服务器点击率增大时，观察 mysql 数据库的最大连接数，仍未超过系统设置的最大连接数。所以，暂时未发现数据库的瓶颈！五结论以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显
12、，比较利于观察的作为分析案例。根据以上综合分析，当前测试环境下，当应用系统产生最大 533.667 的并发压力。平均负载压力114.352。根据分析，用户在 4 个小时的时候，并发数迅速增加前后的值在 400 左右！分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距！转一份在 51testing 上的讨论 如何测试一个门户网站是否可以支持 10 万用户同时在线？ Posted on 2006-11-16 01:21 Jackei 阅读(6074) 评论(5) 编辑 收藏 网摘 所属分类: 04.软件性能测试 这个帖子的内容比较典型，大
13、家有兴趣可以也思考一下。先是楼主提出问题：最近公司一个项目,是个门户网站, 需要做性能测试,根据项目特点定出了主要测试项和测试方案一种是测试几个常用页面能接受的最大并发数(用户名参数化,设置集合点策略)一种是测试服务器长时间压力下,用户能否正常操作( 用户名参数化, 迭代运行脚本)还有一种则需要测试服务器能否接受 10 万用户同时在线操作, 但使用的 Loadrunner 的license 只能支持 1 万用户,请问这时该如何制定该方案?后面跟着大家的回复：网友 xingcyx 的回复：1、找 10 台电脑也没用，license 仍然只支持 10000 个。2、找 HP 支持。当然，前提是你有
14、足够的钱。3、测到 10000 用户并发。我认为，通常情况下 10000 用户并发，支持 100000 用户在线，没有问题的。网友 jackloo 的回复：总的来说这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求。如果是用 IIS 做应用服务器的话，单台可承受的最大并发数不可能达到 10 万级，那就必须要使用集群，通过多台机器做负载均衡来实现；如果是用 websphere 之类的应用服务器的话，单台可承受的最大并发数可以达到 10 万级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现；那么，你只要集群的服务器足够多，10 万并发数当然可以达到了。通常有 1 个
15、简单的计算方式，1 个连接产生 1 个 session，每个 session 在服务器上有个内存空间大小的设置，在 NT 上是 3M，那么 10 万并发就需要 300G 内存，当然实际使用中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。还有 10 万个用户同时在线，跟 10 万个并发数是完全不同的 2 个概念。这个楼上已经说了。但如何做这个转换将 10 万个同时在线用户转换成多少个并发数呢？这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这 2 个数据的比例就是你同时在线用户转换到并发数的比例。另外根据经验统计
16、，对于 1 个 JAVA 开发的 WEB 系统（别的我没统计过，给不出数据），一般 1 台双 CPU、2G 内存的服务器上可支持的最大并发数不超过 500 个（这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义） ，可正常使用（单步非大数据量操作等待时间不超过 20 秒）的最大并发数不超过 300 个。假设你的 10 万同时在线用户转换的并发数是 9000 个，那么你最少需要这样的机器 18台，建议不少于 30 台。当然，你要是买个大型服务器，里面装有 200 个 CPU、256G 的内存，千兆光纤带宽，就算是 10 万个并发用户，那速度，也绝对是嗖嗖的。楼主的回复：谢谢 jackloo !再请问如果我想测试 10000 个用户同时在线做常用操作的话(每两秒加一个用户, 一直加到 10000),对服务器的要求有多高?网友 jackloo 的回复：套用 1 句经典台词“高，实在是高”呵呵。另外暴寒 1 下，你的
