LR性能测试分析方法

第一步：从分析Summary的事务执行情况入手
Summary主要是判定事务的响应时间与
执行情况是否合理。

如果发现问题，则需要做进一步分
析。

通常情况下，如果事务执行情况失败或响应时间过长等，都需要做深入分析。

下面是查看分析概要时的一些原则：（1）：用户是否全部运行，最大运行并发用户数（Maximum Running
Vusers）是否与场景设计
的最大运行并发用户数一致。

如果没有，则需要打开与虚拟用户相关的分析图，进一步分析虚拟用
户不能正常运行的详细原因；
（2）：事务的平均响应时间、90%事务最大响应时间用户是否可以接受。

如果事务响应时间过
长，则要打开与事务相关的各类分析图，深入地分析事务的执行情况；
（3）：查看事务是否全部通过。

如果有事务失败，则需要深入分析原因。

很多时候，事务不能
正常执行意味着系统出现了瓶颈；（4）：如果一切正常，则本次测试没有必要进行深入分析，可以进行加大压力测试；
（5）：如果事务失败过多，则应该降低压力继续进行测试，使结果分析更容易进行；
......
上面这些原则都是分析Summary的一些
常见方法，大家应该灵活使用并不断地进行总结与完善，
尤其要主要结合实际情况，不能墨守成规。

第二步：查看负载生成器和服务器的系统资源情况。

查看分析概要后，接下来要查看负载生成器何待测服务器的系统资源使用情况：查看CPU的利用
率何内存使用情况，尤其要注意查看是否存在内存泄露问题。

这样做是由于很多时候系统出现瓶颈
的直接表现是CPU利用率过高或内存不足。

应高保证负载生成器在整个测试过程中其CPU、内存、带宽没有出现瓶颈，否则测试结果无效。

而待测试服务器，则重点分析测试过程中CPU何内存是否出现了瓶颈：CPU需要查看其利用率是否经
常达到100%或平均利用率一直高居95%
以上；内存需要查看是否够用以及测试过程是否存在溢出现象
（对于一些中间件服务器要查看其分配的内存是否够用）。

第三步：查看虚拟用户与事务的详细执行情况。

在前两部确定了测试场景的执行情况基本正常后，接下来就要查看虚拟用户与事务的执行情
况。

对于虚拟用户，主要查看在整个测试过程中是否运行正常，如果有较多用户不能正常运行，则
需要重新设计场景或调整用户加载与退出方式再次进行测试。

对于事务，重点关注整个过程的事务
响应时间是否逐渐变长以及是否存在不能正常执行的事务。

总之，对每个用户或事务的执行细节都应该认真分析不可轻易忽略；
example1：一个性能逐步下降的服务器，需要进一步分析其性能下降的原因【可以查找是否
存在内存泄露问题】；
example2：一个性能相对稳定的服务器，但是响应时间偏大，这时需要分析程序算法是否存
在缺陷或服务器参数的配置是否合理
- 1 -
__
性能瓶颈分析方法
同一场景
1.小用户量的情况下测试
2.大用户量情况下的测试
分析的方法：
整个系统架构分析，系统响应时间消耗，利用图表分析
查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析window resource图表，查看cpu
使用下列计数器标识cpu瓶颈
Processor\ Interrupts/sec
Processor\ % Processor Time
Process(process)\ % Processor Time System\ Processor Queue Length
通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！
下一步去判断进程，那个进程消耗cpu最高下边就有很多种情况需要你自己去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）
性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。

分析原则：
• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）• 查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，w eb服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。

对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

• 分段排除法很有效
分析的信息来源：
•1 根据场景运行过程中的错误提示信息
•2 根据测试结果收集到的监控指标数据
一．错误提示分析
分析实例：
1 •Error: Failed to connect to server "
10.10.10.30:8080": [10060] Connection •Error: timed out Error: Server "10.1 0.10.30" has shut down the connection p rematurely
分析：
•A、应用服务死掉。

（小用户时：程序上的问题。

程序上处理数据库的问题）
•B、应用服务没有死
（应用服务参数设置问题）
例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的Accep tBacklog属性值设得过低。

如果连接时收到c onnection refused消息，说明应提高该值，每次增加25％
•C、数据库的连接
(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)
2 Error: Page download timeout (120 se conds) has expired 分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多
二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

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

如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。

否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。

使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

• 细分事务并分析每个页面组件的性能。

查看过长的事务响应时间是由哪些页面组件引起
的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。

如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题3．服务器资源监控指标：
内存：
1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。

如果持续很高，则内存可能是瓶颈。

也可能是内存访问命中率低。

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

步骤：
1).首先查看可用内存（Memory\Available Mb ytes）计数器指标。

若值较小则可能有内存问题，需进一步分析。

2).注意Pages/sec（页交换）、Pages Read/ sec（页面读取操作速率）和Page Faults/se c（处理器处理错误页的综合速率）计数器的值。

Pages/sec（页交换）和Page Faults/s ec（处理器处理错误页的综合速率）的值持续很高，很可能内存问题，若Pages Read/sec （页面读取操作速率）的值超过5（一般情况下指的是平均值），则可判断存在内存问题。

3).根据PhysicalDisk计数器的值分析性能瓶颈。

如果磁盘的Average Disk Queue Length （物理磁盘平均队列长度）计数器增加的同时Pages Read/sec（页面读取操作速率）并未降低，则可判断内存有问题。

内存资源成为系统性能的瓶颈的征兆:
很高的换页率(Memory\Pages/sec) (high p ageout rate);
进程进入不活动状态（可用内存的数量很小，但活动的虚拟内存（Committed Bytes）却很大）;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率（很长的运行进程队列，但CPU的空闲时间却很多）;
内存不够出错(Memory\Available Mbytes) (out of memory errors)
处理器：
1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。

可以考虑增加一个处理器或换一个更快的处理器。

如果服务器专用于SQL Server,可接受的最大上限是80-85%
合理使用的范围在60%至70%。

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

CPU资源成为系统性能的瓶颈的征兆: 很慢的响应时间(slow response time) CPU空闲时间为零(zero percent idle C PU)
过高的用户占用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 Queue Length的值很高，而Pag e Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilizat ion)
太长的磁盘等待队列(large disk queue length)
等待磁盘I/O的时间所占的百分率太高(l arge percentage of time waiting for dis k I/O)
太高的物理I/O速率:large physical I/ O rate(not sufficient in itself)
过低的缓存命中率(low buffer cache h it ratio(not sufficient in itself)) 太长的运行进程队列，但CPU却空闲(lar ge run queue with idle CPU)
4．数据库服务器：
SQL Server数据库：
1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。

如果持续低于80%，应考虑增加内存。

2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。

3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。

该计数器的值必须为0。

4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的
值。

Oracle数据库：
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加S HARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率：
select(sum(pins-reloads))/sum(pins) f rom v$librarycache;
select(sum(gets-getmisses))/sum(get s) from v$rowcache;
自由内存： select * from v$sgasta t where name=’free memory’;
2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：
select name,value from v$sysstat wh ere name in ('db block gets’,
'consistent gets','physical reads') ;
Hit Ratio = 1-(physical reads / ( d
b block gets + consistent gets))
3 如果日志缓冲区申请的值较大，则应加大L OG_BUFFER参数的值。

日志缓冲区的申请情况：
select name,value from v$sysstat wh ere name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95，则应加大S ORT_AREA_SIZE以避免磁盘排序。

内存排序命中率：
select round((100*b.value)/decode ((a.value+b.value), 0, 1, (a.value+b.va lue)), 2)from v$sysstat a, v$sysstat b where ='sorts (disk)' and = 'sorts (memory)'
注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Ora cle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。