性能瓶颈分析和性能报告总结

账户管家系统改造性能测试总结和性能瓶颈分析

通过账户管家系统改造项目，下面我就把个人工作中的体会整理出来，希望能对大家在做C/S架构系统的性能测试有所帮助。

1.分析原则：

 

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

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

 

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

 

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

 

1.3 分段排除法 很有效

 

分析的信息来源：

 

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

 

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

 

一．错误提示分析

 

二．分析实例：

1 “Action.c(16): Error : 'Timeout expired while trying to <connection_info> connection. Error code : 9017 ”

分析：loadrunner连接前置超时：（多并发数时前置处理不过来时报这个错误，但是如果不看后台数据库，当前置没有报这个错误时会被假象所迷惑，就是当前置处理完后，并没有把相应的交易发送到后台，而是处理完就返回了）

 

2         Action.c(90): Error : socket0 - Connection refused. Error code : 10061.

分析：应用服应用不在运行状态中

（原因：后台服务器日志文件容量达到2G而造成服务器应用不在运行状态），不过还有其他原因也会引起这个错误

 

如：１.主机地址和端口错误，确定连接了正确的端口和主机地址，如果有网络分析工具，你可以检查一下，端口和主机是不是你要连接的。

２.服务器应用没有运行，检查服务器的应用是不是在运行中，上面就属于这种情况，因为日志太大而服务中断。

３.端口是否被占用，检查服务器的监听端口。

４.如果此问题出现在负载测试中，可能是服务器的socket队列不足了，要解决的话尝试如下：

A:修改服务器的应用以处理更多的请求requests.

B:手工输入如下的相似代码：

 while (lrs_create_socket("socket2", "TCP", "RemoteHost=LDNTAS42:671", LrsLastArg) == 10061) ;

脚本将继续执行直到socket可以连接。

 

3  数据库的连接

 

1、在应用服务的性能参数可能太小了；

2、数据库启动的最大连接数（跟硬件的内存有关）。

 

二．监控指标数据分析

 

1．  最大并发用户数：

 

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

 

在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。但是也有可能程序有bug，当程序有bug的话，一个并发用户连续发送都会有问题，在账户管家系统改造就出现后台调用汇兑主机的接口时，用一个并发用户连续发送，不到五分钟调用tuxedo服务失败，而不能完成交易。

 

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

 

2．  业务操作响应时间：

 

分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务，但是前提是交易都成功，假如设置了事物（开始事务和结束事物）就可以从图中直接得到数据，假如没有设置事物，要看数据库中得到的数据是否和成功的事务相一致，一致的话就可以从摘要图得到，不一致得话平均事务响应时间图和事务性能摘要图就没有什么意义了。

 

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

 

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

 

内存：

 

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

 

2 Windows资源监控中，如果Process/Private Bytes计数器和Process/Working Set计数器的值在长时间内持续升高，同时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/Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

 

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)

 

磁盘I/O：

 

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

 

2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而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) ；

 

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，那么需要增加SHARED_POOL_SIZE的大小。

 

快存（共享SQL区）和数据字典快存的命中率：

 

select(sum(pins-reloads))/sum(pins) from v$librarycache;

 

select(sum(gets-getmisses))/sum(gets) from v$rowcache;

 

自由内存： select * from v$sgastat where name=’free memory’;

 

2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

 

缓冲区高速缓存命中率：

 

select name,value from v$sysstat where name in (’db block gets’, ‘consistent gets’,'physical reads’) ; Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

 

3         如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

 

日志缓冲区的申请情况 ：

 

select name,value from v$sysstat where name = ‘redo log space requests’ ;

 

4         如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

 

内存排序命中率 ：

select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’

 

注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

 

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

一、概述

      性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

·应用在客户端性能的测试

应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

 并发性能测试的重点

并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来,用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、C/S架构和B/S架构等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。

测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。

      并发性能测试前的准备工作

测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。

测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。

在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。

模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如账户管家系统改造中，进行交易的时候，把交易金额进行参数化，这样测试出来的数据才有实际意义。
      并发性能测试的种类与指标

采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。

并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，偏差越大；Median：中值响应时间；90％：90％事务处理的服务器响应时间）、虚拟并发用户数。     

压力负载测试中也需要注意：

1、注意区别内存泄露和动态内存分配问题；

2、注意压力端和服务器端的网络流量，一般来说目前的网络不会是系统的瓶颈，但是也需要注意；

 

以下以账户管家系统改造为例，定义一个C/S架构模式下的性能指标：

生产环境服务器配置：CPU*2；4G内存；300G硬盘*6；网络带宽2M

环境配置根据不同的系统存在很大差异，但是也有一定的规律可循，或者说一般也有一些通用的原则：

1、所有事务响应时间，其中包括登陆、交易和报表查询等：3秒之内（非常好）、3-5秒（一般）、5-8秒（免强接受）、8秒以内（用户不能接受），遵循3、5、8原则；

2、每分钟至少可以处理600笔交易；

3、每秒事务数：80%的事务在20%的时间内完成（一年按160天算，一天8小时算），遵循80-20原则；

4、服务器在受压情况下，cpu最佳占用率为60%~80%，多了cpu受不了，少了资源浪费；

5、服务器在不受压情况下，内存占用率最佳为25%，多了影响服务器性能；