性能测试如何对瓶颈进行定位？(2011-3-14)（获奖名单已公布）

默默巫

性能测试如何对瓶颈进行定位?

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	zhyb_2008	价值50元礼品	5#
二等奖	xiangxiang	300论坛积分	4#
三等奖	winnie060606	100论坛积分	7#

zhyb_2008

这个问题好大，不知道怎么回答，就说一些日常的分散的工作过程和感觉吧：
    性能测试的概念是什么，基本目的是什么，我想大家都基本清楚，不作详述，总之，性能测试只是测试过程中的一种方式，帮助我们的功能更好的运行，如果功能测试是可用，易用，满足需求、用户使用为目的，性能测试无非就是让这些目的更流畅。没有什么专业的概念，无非实现两个字：好用！
    所以，性能测试这种测试方式在发生过程中，其中一个过渡性的工作，就是对执行过程中的问题，进行定位，对功能的定位，对负载的定位，最重要的，当然就是问题中说的“瓶颈”，接触性能测试不深，更非专家，自己的理解，瓶颈产生在以下几方面：
1，网络瓶颈，如带宽，流量等形成的网络环境
2，应用服务瓶颈，如中间件的基本配置，CACHE等
3，系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
4，数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
5，应用程序本身瓶颈，
以上几方面分别唠叨几句
      针对网络瓶颈，现在冒似很少，不过也不是没有，首先想一下如果有网络的阻塞，断网，带宽被其他资源占用，限速等情况，应用程序或系统会是什么情况，针对WEB，无非是超时，HTTP400，500之类的错，针对一些客户端程序，可能也是超时，掉线，服务器下发的，需要服务器返回的信息获取不到还有一种更明显的情况，应该就是事务提交慢，如果封装事务的代码再不完善，一般造成的错误，无非就是数据提交不完整，或者因为网终原因+代码缺陷造成重复性提交。如此综合下来，肯定是考虑网络有瓶颈，然后考虑网络有问题时，怎样去优化，是需要优化交互的一些代码，还是接口之类的。
      应用服务的瓶颈的定位，比较复杂，学习中，不过网上有很多资料可以参考的。一般像tomcat，weblogic之类的，有默认的设置，也有经过架构和维护人员进行试验调试的一些值，这些值一般可以满足程序发布的需要，不必进行太多的设置，可能我们认识的最基本的就是JAVA_OPTS的设置，maxThreads,time_out之类的参数我们做借助LR，Jemeter或webload之类的工具，执行性能测试，尤其是对应用服务造成了压力，如果应用服务有瓶颈，一般我们设置的log4j.properties，日志都会记录下来。然后根据日志，去进一步确定应用服务的问题
      系统瓶颈，这个定位虽说比较复杂，但是有很多前辈的经验值参考，不作说明，相信用LR的同行，也可以从性能记数器中得出一些指标值，加上nagios，cacti，可以很明显的看出系统哪些资源够用，哪些资源明显不够用。不过，一般系统瓶颈的造成，是因为应用程序本身造成的。关于这点儿的分析和定位，就需要归入应用程序本身瓶颈分析和定位了。
      现在基本所有的东东，都离不开数据库这个后台，数据库的瓶颈实在是不知道是什么概念，数据库管理员的工作，数据库管理员日常做的工作，可能就是有瓶颈定位的工作，比如：查询一下V$sys_event,V$sysstat,v$syssql之类的表，比对一下日常正常情况下的监控数据，看一下有没有异常等。其他方面，我也不是太了解。
      应用程序瓶颈，这个是测试过程中最需要去关注的，需要测试人员和开发人员配合执行，然后定位，我这儿做的大都是执行性的，比如会有脚本去运行，开发人员会结合jprofiler之类的工具，去看一下堆遍历，线程剖析的情况确定哪儿有问题。大致是这样，没有实际操作过

      等待有更好的定位分析方式方法，如果可以，希望回贴的其他同行可以把相关方面的技术文章链接也发一下。我这儿比较
零散，就不献了。
附：很早前做的一个简单的性能测试过程：

madwolfer

都是狗屁“砖家”，都是些夸夸其谈的内容；没有任何得实际意义！一群垃圾！
zhifei.xie 发表于 2011-5-9 14:07

你想要什么，告诉我。

zhifei.xie

都是狗屁“砖家”，都是些夸夸其谈的内容；没有任何得实际意义！一群垃圾！

wlpandlb

回复 5# zhyb_2008

您好，能否指导一下菜鸟，
怎么可以按那些基础数据设计出报告中相应的场景。谢谢了~~~

y_test

学习一下

jasonxu

回复 13# helengreens
服务器连接数超过上限  ，请问如何判断Linux的连接数超过上限

dq_0413

推荐一本好书《软件性能测试过程详解与案例剖析.pdf》 里面讲的很详细。

悾歽枝

学习学习

541026287

学习ing

cebio

性能瓶颈分析是个难点，我经验也比较有限，只简单说说。

我测过的系统主要是典型的ASP.NET开发的web应用
1.当然是用LR模拟性能需求场景，记录各项指标
一是度量，比如说页面加载响应慢，慢到什么程度要有个定量指标
二是对比，在确定瓶颈调优后对比测试结果

2.按领域逐类别分析，上面已经有很详细的图了，对照之后逐项分析排查

在硬件级，看是否能用几组不同性能的服务器作对比分析，看系统性能是否能随服务器性能改善线性增加

在服务器级，做一下设置方面调整，内存、缓存、IO、应用池、web园等，看是否性能有明显改善

在应用程序级，用LR的页面细分
看一下Time to First Buffer，看是服务器问题还是网络问题，一般都是服务器端（排除另一个）
找响应时间长的页面，看下Download Time，Component，注意到页面上有类元素加载次数较多，虽然单个的加载时间极短，但由于重复个数较多，所以总页面响应时间上去了。查看这个元素，是一棵树上的节点，由开发静态走查涉及的程序块，发现一次性把整个节点树都加载到页面了，在小数据量情况下问题不明显，但大数据量下对性能影响很大。另外就是最白盒检查，分析哪些函数调用次数比较多，有一些专门工具辅助。

在数据库级，用sqlProfiler跟踪提交语句，或者用sqlserver统计视图显示提交语句统计信息，将占用资源过多的语句进行执行计划分析，用引擎优化顾问尝试优化
用活动监视器看连接情况，锁情况，有一次就发现数据库连接使用完后没立即释放，当并发后数据库连接池就爆满了。另一个就是对临界资源的并发，一般开发提交事务时一般只会用一个线程自测，并发测试后就容易出问题，出现问题后，看一下相关系统日志是否有记录，或者让开发写程序日志，加入调试信息，打印日志（所以性能测试需要团队合作，很多时候最开始只是一些不明显的症状，需要开发调试后才能进一步确认瓶颈）

在客户端，注意到IE和chrome页面呈现速度差别比较大，究其原因在于chrome用的解析引擎对javascript有极快的渲染速度，没什么太好解决方法，只能建议客户升级到高版本IE

3.同行产品比对，确定阀值
有时用一般的页面响应标准也不知道适不适合本系统业务，所以找同类业务的开源产品，比如登录什么的，评估一下，确定响应阀值（这样定的阀值比较有说服力，别人能做到的我们也应该行，超过这个阀值就要优化），通过学习他的方式。

dq_0413

学习了图表分析是性能测试中最关键的一项，现在却挺迷茫的。不知道如何下手，只会从 服务器资源使用情况进行评估。

51mobile

回复 17# yushudd


    这个不错

cppbaby

这个问题要先隔离，再寻找。
先隔离，分清性能瓶颈是由于外部原因还是内部原因。
太多都是在强调外部原因，譬如测试机硬件，譬如网络，譬如存储。。。如果过分纠结这些方面，那无异于在给自己软件的性能问题找借口找理由，不可取。
隔离出来外部原因后，寻找一种可靠的衡量方式，以此作为测试的基准，标杆，然后进入自身原因，检查是否条件判断循环流程复杂，可以复用的数据没有保存在共享内存而是每次都要读取，可以异步实现的过程却使用了同步，或者在本身已经很复杂的系统中使用了多进程而不是多线程。

hyd_bpmf

。。。附件。。。付费。。。

yushudd

我们先来看一下性能测试过程，再来说如何做瓶颈分析：
分析用户需求
设计测试用例
收集测试结果
性能瓶颈分析
关键点故障诊断
性能调优建议

    我们看到瓶颈分析的大前提是数据收集。社会科学的每一项分析都是基于大量的数据统计，性能测试也不例外。要想做好性能分析，请先学会数据收集。

这里为大家介绍一些基本工具，下述工具源于网络收集。欢迎其他同学补充。
Quest on Websphere：监控web service
quest UNIX：监控unix
webspere：监控webspace
spotlight：操作系统监控工具。
jconsole：jmx方式诊断；java自带的诊断jvm的工具[java1.5以上版本都有，同Quest on Websphere原理一样]
performasure：bci方式诊断；对jvm进行诊断，可到java代码一级
Jwebap：bci方式诊断；开源的工具;用于J2EE工程（EJB以及WebModule系统）进行性能监控的组件.
JProfiler:是一个全功能的Java剖析工具（profiler）,专用于分析J2SE和J2EE应用程序.
cacti： 网络流量监控。
foglight：Quest 的高级应用监控解决方案，可以对所有影响 IT 性能的服务器、数据库、操作系统、 Web Sever 和网络进行监控和管理。
rational purifyPlus：针对C#的工具；
lambda probe：tomcat监控工具。
数据库方面，大部分数据库都自带强大的监控工具，暂不做介绍。

    有了数据，但是如果不知道数据代表什么含义，我们的分析工作一样无法继续。所有夯实的计算机基础知识是非常必要的。熟悉被测试系统的开发语言，熟练掌握数据库知识，了解被测试系统的软件架构，计算机体系结构，各种网络协议，各种中间件、服务器的配置等等，等等。

    有了完备的数据收集，坚实的计算机基础，还怕做不好性能分析吗？

    个人认为、测试人员如果只是在性能测试过程中承担施压方，分析和调优大部分同其他的同事合作完成，不利于测试人员性能测试的发展，也不利于性能测试本身的开展。

    基于Lr的性能测试，请善加利用lr中的各种监控数据。


附一：性能数据收集关键点
客户端性能指标：并发用户数、事务响应时间、每分钟事务数
非客户端性能指标：服务器资源、网络资源
操作系统：例如Windows平台、Unix平台
数据库服务器：例如Oracle、DB2、Sybase、 SQLServer
中间件服务器：例如WebSphere、WebLogic
网络：带宽利用率、延迟、丢包、传输错误等
oracle数据库：
内存利用：
db block gets
db block changes
global cache gets
global cache get time
事件统计：
enqueue waits
shared hash latch upgrades - no wait
shared hash latch upgrades - wait
redo log space wait time
SQL分析：
table scan rows gotten
table scans(long tables)
table scans(short tables)
index fast full scans (full)
会话统计：
session logical reads
session stored procedure space
CPU used by this session
session connect time
附二：性能分析关键点
响应时间
并发用户数
吞吐量
cpu
内存和高速缓存
磁盘
中间件服务器性能
数据库服务器性能

附三：附件为性能分析图

futogether

回复 15# mlj_12


   这个问题太大了，实在不好回答

  专注ing

mlj_12

没什么人回答啊！哎

helengreens

原来回复要审核的啊。。。发重了。。。

helengreens

碰到过的性能问题：
1.在高并发的情况下，产生的处理失败（比如：数据库连接池过低，服务器连接数超过上限，数据库锁控制考虑不足等）
2.内存泄露（比如：在长时间运行下，内存没有正常释放，发生宕机等）
3.CPU使用偏离（比如：高并发导致CPU使用率过高）
4.日志打印过多，服务器无硬盘空间

如何定位这些性能问题：
1.查看系统日志，日志是定位问题的不二法宝，如果日志记录的全面，很容易通过日志发现问题。
  比如，系统宕机时，系统日志打印了某方法执行时抛出out of memory的错误，我们就可以顺藤摸瓜，很快定位到导致内存溢出的问题在哪里。
2.利用性能监控工具，比如：JAVA开发B/S结构的项目，可以通过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。
利用Spotlight可以监控数据库使用情况。
我们需要关注的性能点有：CPU负载，内存使用率，网络I/O等
3.工具和日志只是手段，除此之外，还需要设计合理的性能测试场景
具体场景有：性能测试，负载测试，压力测试，稳定性测试，浪涌测试等
好的测试场景，能更加快速的发现瓶颈，定位瓶颈
4.了解系统参数配置，可以进行后期的性能调优

除此以外，还想说个题外话，就是关于性能测试工具的使用问题
在刚开始用Loadrunner和JMeter的时候，做高并发测试时，都出现过没有把服务器压垮，这两个程序自己先倒下的情况
如果遇到这个问题，可以通过远程调用多个客户端的服务，分散性能测试工具客户端的压力来解决
说这个的目的是想说，做性能测试的时候，我们一定要确保瓶颈不要发生在我们自己的测试脚本和测试工具上

以上是我个人的一些观点，抛砖引玉，欢迎拍砖~

helengreens

碰到过的性能问题：
1.在高并发的情况下，产生的处理失败（比如：数据库连接池过低，服务器连接数超过上限，数据库锁控制考虑不足等）
2.内存泄露（比如：在长时间运行下，内存没有正常释放，发生宕机等）
3.CPU使用偏离（比如：高并发导致CPU使用率过高）
4.日志打印过多，服务器无硬盘空间

如何定位这些性能问题：
1.查看系统日志，日志是定位问题的不二法宝，如果日志记录的全面，很容易通过日志发现问题。
  比如，系统宕机时，系统日志打印了某方法执行时抛出out of memory的错误，我们就可以顺藤摸瓜，很快定位到导致内存溢出的问题在哪里。
2.利用性能监控工具，比如：JAVA开发B/S结构的项目，可以通过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。
利用Spotlight可以监控数据库使用情况。
我们需要关注的性能点有：CPU负载，内存使用率，网络I/O等
3.工具和日志只是手段，除此之外，还需要设计合理的性能测试场景
具体场景有：性能测试，负载测试，压力测试，稳定性测试，浪涌测试等
好的测试场景，能更加快速的发现瓶颈，定位瓶颈
4.了解系统参数配置，可以进行后期的性能调优

除此以外，还想说个题外话，就是关于性能测试工具的使用问题
在刚开始用Loadrunner和JMeter的时候，做高并发测试时，都出现过没有把服务器压垮，这两个程序自己先倒下的情况
如果遇到这个问题，可以通过远程调用多个客户端的服务，分散性能测试工具客户端的压力来解决
说这个的目的是想说，做性能测试的时候，我们一定要确保瓶颈不要发生在我们自己的测试脚本和测试工具上

以上是我个人的一些观点，抛砖引玉，欢迎拍砖~