性能分析原则

分析原则：

具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）〉服务器操作系统瓶颈（参数配置）〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

 

分段排除法  很有效

分析的信息来源：

1）根据场景运行过程中的错误提示信息

2）根据测试结果收集到的监控指标数据

 

一．错误提示分析

 

分析实例：

1）Error:  Failed to connect to server"payment.baihe.com″: [10060] Connection

Error: timed out Error: Server "user.baihe.com″ has shutdown the connection  prematurely

分析：

A、应用服务死掉。

（小用户时：程序上的问题。程序上处理数据库的问题）

B、应用服务没有死

（应用服务参数设置问题）

例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection  refused消息，说明应提高该值，每次增加25％

C、数据库的连接

(1、在应用服务的性能参数可能太小了  2、数据库启动的最大连接数（跟硬件的内存有关）)

2）Error: Page downloadtimeout (120 seconds) has  expired

分析：可能是以下原因造成

A、应用服务参数设置太大导致服务器的瓶颈

B、页面中图片太多

C、在程序处理表的时候检查字段太大多

 

二．监控指标数据分析

 

1．最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

 

如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

 

2．业务操作响应时间：

 

分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用"事务性能摘要"图，可以确定在方案执行期间响应时间过长的事务。

 

细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

 

如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用"网络监视器"图确定导致性能瓶颈的网络问题

 

2-5-10原则：简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求

 

3．服务器资源监控指标：

 

内存：

 

1）UNIX资源监控中指标内存页交换速率（Paging  rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

 

2）Windows资源监控中，如果Process\Private  Bytes计数器和Process\WorkingSet计数器的值在长时间内持续升高，同时Memory\Available  bytes计数器的值持续降低，则很可能存在内存泄漏。

 

内存资源成为系统性能的瓶颈的征兆:

 

很高的换页率(high  pageout  rate);

 

进程进入不活动状态;

 

交换区所有磁盘的活动次数可高;

 

可高的全局系统CPU利用率;

 

内存不够出错(out of memory  errors)

 

处理器：

 

1）UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU  utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL  Server,可接受的最大上限是80-85%

 

合理使用的范围在60%至70%。

 

2）Windows资源监控中，如果System\ProcessorQueue  Length大于2，而处理器利用率（ProcessorTime）一直很低，则存在着处理器阻塞。

 

CPU资源成为系统性能的瓶颈的征兆:

 

很慢的响应时间(slow response time)

 

CPU空闲时间为零(zero percentidle CPU)

 

过高的用户占用CPU时间(high percent user CPU)

 

过高的系统占用CPU时间(high  percent system CPU)

 

长时间的有很长的运行进程队列(large run queue size sustained over time)

 

磁盘I/O：

 

1）UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk  rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

 

2）Windows资源监控中，如果Disk  Time和Avg.Disk QueueLength的值很高，而Page  Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

 

I/O资源成为系统性能的瓶颈的征兆  :

 

过高的磁盘利用率(high disk utilization)

 

太长的磁盘等待队列(large disk queue  length)

 

等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk  I/O)

 

太高的物理I/O速率:large physical I/O rate(not sufficient in itself)

 

过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))

 

太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

分析原则：

　　1. 具体问题具体分析(这是由于不同的应用系统，不同的测试目的，不同的性能关注点)

　　2. 查找瓶颈时按以下顺序，由易到难。

　　服务器硬件瓶颈网络瓶颈(对局域网，可以不考虑) 服务器操作系统瓶颈(参数配置) 中间件瓶颈(参数配置，数据库，web服务器等) 应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)

　　分析的信息来源：

　　1. 根据场景运行过程中的错误提示信息

　　2. 根据测试结果收集到的监控指标数据

　　一.错误提示分析

　　分析实例：

　　1.Error: Failed to connect to server “172.17.7.230″: [10060]Connection

　　Error: timed out Error: Server “172.17.7.230″ has shutdown the connection prematurely

　　分析：

　　A、应用服务死掉。

　　(小用户时：程序上的问题。程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题)

　　B、应用服务没有死

　　(应用服务参数设置问题)

　　对应的Apache和tomcat的最大链接数需要修改，如果连接时收到connection refused消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况和服务器硬件的情况来定，建议每次增加25%!

　　C、数据库的连接

　　(数据库启动的最大连接数(跟硬件的内存有关))

　　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、脚本设计问题，例如，前一脚本修改了某些内容，造成后面的脚本访问异常。

　　B、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。只能反复修改脚本!

　　二.监控指标数据分析

　　1.Vusers数

　　Loadrunner 系统设置的虚拟用户数目。Vuser去实际调用事先制作的脚本文件中的应用。

　　每个Vuser产生响应的操作，所有的操作对服务器形成并发。

　　颜色比例 度量 图最小值 图平均值 图最大值 图中间值 图SD

　　1 Run 0.0 21.25 44 41 21.276

　　在实际测试中，Vusers可以根据实际情况的需要，在测试过程中增加或者减少。

　　2.最大并发用户数：

　　颜色比例 度量 最小值 平均值 最大值 SD

　　100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043

　　0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924

　　0.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 生成的负载数。

　　颜色比例 度量 图最小值 平均值 图最大值 图中间值 图SD

　　1 点击次数 69.908 105.736 130.244 103.666 12.186

　　从图中不难看出，在4小时的时候，点技数明显增高。和apache的每秒点击数增大的时间相吻合!

　　5.吞吐量

　　负载测试期间 Web 服务器上的吞吐量(字节)。吞吐量表示在任何指定秒内 Vuser 从服务器接收到的数据量。此图可估计 Vuser 生成的负载量(服务器吞吐量)。

　　颜色比例 度量 图最小值 平均值 图最大值 图中间值 图SD

　　1 Throughput 1257502.795 1375591.372 1525865.047 1372743.69149130.473

　　同样，从图中可以看出，在4个小时的时候，web服务器的吞吐量开始增高。

 

在图中还可以看到吞吐量的走势图，从开始到进行到4个小时反弹之前呈降低的趋势，这是因为系统在初期调用的资源都是直接来之服务器，运行一段时间后系统的部分资源来自缓存。

　　6.下载组件大小

　　每个页面的组件大小，且包括组件的标头的大小!

　　页面组件大小的分析表格比较复杂，实际分析中可以通过loadrunner的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件，如果其影响到了页面的下载速度，则要想办法将其改小!

　　7.Apache资源

　　显示APACHE web服务器上的资源摘要。前面已经提到过以并发点击数为主。

　　颜色比例 度量 最小值 平均值 最大值 SD

　　100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043

　　0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924

　　0.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201

　　三.服务器资源监控指标

　　(目前通过top监察)

　　内存：

　　Linux资源监控中指标内存页交换速率(Paging rate)，如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

　　实际测试中，当并发点击数出现突然剧增前后，内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈!

　　内存资源成为系统性能的瓶颈的征兆:

　　很高的换页率(high pageout rate);

　　进程进入不活动状态;

　　交换区所有磁盘的活动次数可高;

　　可高的全局系统CPU利用率;

　　内存不够出错(out of memory errors)

　　处理器：

　　Linux资源监控中指标CPU占用率持续超过80%(对该值的要求，根据具体应用和机器配置而要求不同，有资料表明95%)，表明瓶颈是CPU。

　　实际测试中，当并发点技数出现突然增加前后，cpu的占用率持续保持在86%以上!

　　说明，目前系统用应用的cpu也是测试的瓶颈!

　　CPU资源成为系统性能的瓶颈的征兆:

　　很慢的响应时间(slow response 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数据库的最大连接数，仍未超过系统设置的最大连接数。所以，暂时未发现数据库的瓶颈!

　　五.结论

　　以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显，比较利于观察的作为分析案例。

　　根据以上综合分析，当前测试环境下，当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析，用户在4个小时的时候，并发数迅速增加前后的值在400左右!分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距!