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