对于性能测试结果的分析原则

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

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

　　服务器硬件瓶颈-〉网络瓶颈(对局域网，可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置，数据库，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 shut down the connection prematurely

　　分析：

　　A、应用服务死掉。

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

　　B、应用服务没有死

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

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

　　C、数据库的连接

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

　　2)Error: Page download timeout (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\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

原文转自：http://www.ltesting.net