51Testing软件测试论坛

标题: 性能测试如何对瓶颈进行定位？(2011-3-14)（获奖名单已公布） [打印本页]
作者: 默默巫    时间: 2011-3-14 13:23
标题: 性能测试如何对瓶颈进行定位？(2011-3-14)（获奖名单已公布）
性能测试如何对瓶颈进行定位?

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



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

作者: cq_java    时间: 2011-3-14 14:34
抢个沙发，这个问题很难回答
作者: mlj_12    时间: 2011-3-14 16:42
性能瓶颈定位:首先查找形成系统瓶颈或者故障的根本原因，其次是进行性能调整和优化，最后便是评估性能调整的结果。
作者: xiangxiang    时间: 2011-3-15 10:17
谈谈我的看法。
1.首先，需要make sure我们的性能测试的target是合适的。用户如何使用我们的系统，也就是用户的使用模型。确定我们的性能测试确实是cover了大多数用户的使用模型。这是性能瓶颈分析的前提，以免浪费时间和精力。
2.得出一个task性能数据，接下来需要做task分解。一个task在CPU或者多个主机上执行，无非就是串行task和并行task。对于串行执行的任务好说，每个sub task的执行时间是多少，多者既瓶颈所在，需要对它优化。并行也好说，总体的性能既是所有并行的sub task中耗时最长的那一个，它既是瓶颈，需要对它优化才能提高整体性能。
如果一个task既串行，有并行，相互交织，相互混杂。那就只有像庖丁解牛一样，逐级划分，直到变成并行和串行的sub sub sub task。然后就可以得出task的总的耗时和这些sssssub task的执行时间的数学关系。瓶颈定位就变成数学公式，看起来就简单了是吧。
3.第2条是针对一个测试性能数据而言的。如果很多的测试用例走了不同的分支，既不同的sub task，使得按照2得到不同的公式，问题就变成如下的：
TC1 Perf Bottleneck = F1(sub1, sub2, sub3,...)
TC2 Perf Bottleneck = F2(sub1, sub2, sub3,...)
TC3 Perf Bottleneck = F3(sub1, sub2, sub3,...)
TC4 Perf Bottleneck = F4(sub1, sub2, sub3,...)
...
也就是说最终系统的性能在不同的测试用例的情况下，得到的和sub task的关系是不一样的。那么如果我们需要提高整个系统的总体性能，也就是找到谁才是最需要被优化的sub task，我们还是的回到用户模型。针对用户模型的时间分析，我们可以得出每个test case的用户使用概率百分比。例如：TC1 10%，TC2 40%， TC3 10%， TC4 20%。有了这样的数据，带入F1，F2，F3和F4，就大致可以搞清楚哪些sub task是最主要的瓶颈。
4.此外，还需考虑task只能到底耗费的是什么资源，是CPU，是harddisk，是网络带宽。这个取决于你的task划分的粒度以及对每个sub task实现细节的了解。
作者: zhyb_2008    时间: 2011-3-16 15:09
本帖最后由 zhyb_2008 于 2011-3-22 17:16 编辑

这个问题好大，不知道怎么回答，就说一些日常的分散的工作过程和感觉吧：
    性能测试的概念是什么，基本目的是什么，我想大家都基本清楚，不作详述，总之，性能测试只是测试过程中的一种方式，帮助我们的功能更好的运行，如果功能测试是可用，易用，满足需求、用户使用为目的，性能测试无非就是让这些目的更流畅。没有什么专业的概念，无非实现两个字：好用！
    所以，性能测试这种测试方式在发生过程中，其中一个过渡性的工作，就是对执行过程中的问题，进行定位，对功能的定位，对负载的定位，最重要的，当然就是问题中说的“瓶颈”，接触性能测试不深，更非专家，自己的理解，瓶颈产生在以下几方面：
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之类的工具，去看一下堆遍历，线程剖析的情况确定哪儿有问题。大致是这样，没有实际操作过

      等待有更好的定位分析方式方法，如果可以，希望回贴的其他同行可以把相关方面的技术文章链接也发一下。我这儿比较
零散，就不献了。
附：很早前做的一个简单的性能测试过程：
[attach]72078[/attach][attach]72077[/attach]
作者: 夏沫槿年    时间: 2011-3-16 15:20
我是新手，发表一下自己的看法。我觉得统归就是先找到造成瓶颈的原因，然后解决。但是这个原因和解决方法就是因人而异了
作者: winnie060606    时间: 2011-3-16 15:43
以下是个人查找到的资料，学习学习
个人感觉要逐步细化分析，先可以监控一些常见衡量CPU，内存，磁盘的性能指标，进行综合分析，然后根据所测系统具体情况，进行初步问题定位，然后确定更详细的监控指标来分析。

怀疑内存不足时：
方法1：
【监控指标】：Memory Available MBytes ，Memory的Pages/sec, page read/sec, Page Faults/sec
【参考值】：
如果 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。
Page/sec 推荐00-20（如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题）。

方法2：根据Physical Disk 值分析性能瓶颈
【监控指标】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length
【参考值】：%Disk Time建议阈值90%
        当内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。

怀疑内存泄漏时
   【监控指标】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time
【说明】：
Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验。


CPU分析
【监控指标】：
System %Processor Time CPU，Processor %Processor Time CPU
Processor%user time 和Processor%Privileged Time
system\Processor Queue Length
Context Switches/sec 和%Privileged Time
【参考值】：
System\%Total processor time不持续超过90%，如果服务器专用于SQL Server,可接受的最大上限是80-85% ，合理使用的范围在60%至70%。
Processor %Processor Time小于75%
system\Processor Queue Length值,小于CPU数量的总数+1

CPU瓶颈问题
1：System\%Total processor time如果该值持续超过90%,且伴随处理器阻塞，则说明整个系统面临着处理器方面的瓶颈.
注: 在某些多CPU系统中,该数据虽然本身并不大,但CPU之间的负载状况极不均衡,此时也应该视作系统产生了处理器方面的瓶颈.
2：排除内存因素，如果Processor %Processor Time计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU 瓶颈。（内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。）

造成高CPU使用率的原因：
频繁执行程序，复杂运算操作，消耗CPU严重
数据库查询语句复杂，大量的 where 子句，order by, group by 排序等，CPU容易出现瓶颈
内存不足，IO磁盘问题使得CPU的开销增加


磁盘I/O分析
【监控指标】：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time,Physical Disk\ Avg.Disk Queue Length， Disk sec/Transfer
【参考值】：%Disk Time建议阈值90%


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

Processor%Privileged Time该参数值一直很高,且如果在 Physical Disk 计数器中,只有%Disk time 比较大,其他值都比较适中,硬盘可能会是瓶颈。若几个值都比较大, 那么硬盘不是瓶颈。若数值持续超过80%,则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。

Disk sec/Transfer 一般来说,该数值小于15ms为最好,介于15-30ms之间为良好,30-60ms之间为可以接受,超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了.
作者: caiw0418    时间: 2011-3-16 16:19
Average Transaciton Response Time（事务平均响应时间）随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势
Transactions per Second（每秒通过事务数/TPS）当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈
Hits per Second（每秒点击次数）通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
Throughput（吞吐率）可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
Connections（连接数）当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）
Time to First Buffer Breakdown(Over Time)（第一次缓冲时间细分(随时间变化)）可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
作者: futogether    时间: 2011-3-17 10:40
其实，看到这个题目，个人对问题的理解有以下两个方面
1、拿到一个产品，通过测试方法确定是哪种性能瓶颈。如：CPU瓶颈、内存不足、数据库死锁等等
2、已经能预测到是哪些地方能出现性能瓶颈，通过测试方法具体定位造成这种性能瓶颈的原因。如：已确定内存泄露是瓶颈，那可能造成内存泄露的原因是什么，如何定位内存泄露的本源。

性能测试需要测试到哪个深度，瓶颈定位到哪个级别，应该怎么看待这个问题呢？
作者: 真实的追求者    时间: 2011-3-17 14:41
这个问题作为新手来说 还需要很好的分析、理解 学习了
作者: helengreens    时间: 2011-3-18 01:29
碰到过的性能问题：
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    时间: 2011-3-18 01:30
碰到过的性能问题：
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    时间: 2011-3-18 01:32
碰到过的性能问题：
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    时间: 2011-3-18 01:36
本帖最后由 helengreens 于 2011-3-18 11:15 编辑

原来回复要审核的啊。。。发重了。。。
作者: mlj_12    时间: 2011-3-18 16:28
没什么人回答啊！哎
作者: futogether    时间: 2011-3-21 09:44
回复 15# mlj_12


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

  专注ing
作者: yushudd    时间: 2011-3-22 14:40
本帖最后由 yushudd 于 2011-3-23 15:05 编辑

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

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

这里为大家介绍一些基本工具，下述工具源于网络收集。欢迎其他同学补充。
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
内存和高速缓存
磁盘
中间件服务器性能
数据库服务器性能

附三：附件为性能分析图

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


    这个不错
作者: dq_0413    时间: 2011-3-31 11:13
学习了图表分析是性能测试中最关键的一项，现在却挺迷茫的。不知道如何下手，只会从 服务器资源使用情况进行评估。
作者: cebio    时间: 2011-3-31 12:16
性能瓶颈分析是个难点，我经验也比较有限，只简单说说。

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

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

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

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

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

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

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

3.同行产品比对，确定阀值
有时用一般的页面响应标准也不知道适不适合本系统业务，所以找同类业务的开源产品，比如登录什么的，评估一下，确定响应阀值（这样定的阀值比较有说服力，别人能做到的我们也应该行，超过这个阀值就要优化），通过学习他的方式。
作者: 541026287    时间: 2011-3-31 14:48
学习ing
作者: 悾歽枝    时间: 2011-4-1 15:45
学习学习
作者: dq_0413    时间: 2011-4-2 10:38
推荐一本好书《软件性能测试过程详解与案例剖析.pdf》 里面讲的很详细。
作者: jasonxu    时间: 2011-4-6 20:21
回复 13# helengreens
服务器连接数超过上限  ，请问如何判断Linux的连接数超过上限
作者: y_test    时间: 2011-4-21 12:45
学习一下
作者: wlpandlb    时间: 2011-4-29 16:50
回复 5# zhyb_2008

您好，能否指导一下菜鸟，
怎么可以按那些基础数据设计出报告中相应的场景。谢谢了~~~
作者: zhifei.xie    时间: 2011-5-9 14:07
都是狗屁“砖家”，都是些夸夸其谈的内容；没有任何得实际意义！一群垃圾！
作者: madwolfer    时间: 2011-5-9 17:50
都是狗屁“砖家”，都是些夸夸其谈的内容；没有任何得实际意义！一群垃圾！
zhifei.xie 发表于 2011-5-9 14:07

你想要什么，告诉我。



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2