如何给软件性能测试定位

　　2、应用服务瓶颈，如中间件的基本配置，CACHE等

　　3、系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置

　　4、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置

　　5、应用程序本身瓶颈，

　　针对网络瓶颈，现在冒似很少，不过也不是没有，首先想一下如果有网络的阻塞，断网，带宽被其他资源占用，限速等情况，应用程序或系统会是什么情况，针对WEB，无非是超时，HTTP400，500之类的错，针对一些客户端程序，可能也是超时，掉线，服务器下发的，需要服务器返回的信息获取不到还有一种更明显的情况，应该是事务提交慢，如果封装事务的代码再不完善，一般造成的错误，无非是数据提交不完整，或者因为网终原因+代码缺陷造成重复性提交。如此综合下来，肯定是考虑网络有瓶颈，然后考虑网络有问题时，怎样去优化，是需要优化交互的一些代码，还是接口之类的。

　　应用服务的瓶颈的定位，比较复杂，学习中，不过网上有很多资料可以参考的。一般像tomcat，weblogic之类的，有默认的设置，也有经过架构和维护人员进行试验调试的一些值，这些值一般可以满足程序发布的需要，不必进行太多的设置，可能我们认识的基本的是JAVA_OPTS的设置，maxThreads，time_out之类的参数我们做借助loadrunner/" target="_blank" >LR，Jemeter或webload之类的工具，执行性能测试，尤其是对应用服务造成了压力，如果应用服务有瓶颈，一般我们设置的log4j.properties，日志都会记录下来。然后根据日志，去进一步确定应用服务的问题

　　系统瓶颈，这个定位虽说比较复杂，但是有很多前辈的经验值参考，不作说明，相信用LR的同行，也可以从性能记数器中得出一些指标值，加上nagios，cacti，可以很明显的看出系统哪些资源够用，哪些资源明显不够用。不过，一般系统瓶颈的造成，是因为应用程序本身造成的。关于这点儿的分析和定位，需要归入应用程序本身瓶颈分析和定位了。

　　现在基本所有的东东，都离不开数据库这个后台，数据库的瓶颈实在是不知道是什么概念，数据库管理员的工作，数据库管理员日常做的工作，可能是有瓶颈定位的工作，比如：查询一下V$sys_event，V$sysstat，v$syssql之类的表，比对一下日常正常情况下的监控数据，看一下有没有异常等。其他方面，我也不是太了解。

　　应用程序瓶颈，这个是测试过程中需要去关注的，需要测试人员和开发人员配合执行，然后定位，我这儿做的大都是执行性的，比如会有脚本去运行，开发人员会结合jprofiler之类的工具，去看一下堆遍历，线程剖析的情况确定哪儿有问题。大致是这样，没有实际操作过

　　逐步细化分析，先可以监控一些常见衡量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 ，ProcessPrivate Bytes和ProcessWorking Set，PhysicalDisk/%Disk Time

　　【说明】：

　　Windows资源监控中，如果ProcessPrivate Bytes计数器和ProcessWorking Set计数器的值在长时间内持续升高，同时MemoryAvailable bytes计数器的值持续降低，则很可能存在内存泄漏。内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验。

　　CPU分析

　　【监控指标】：

　　System %Processor Time CPU，Processor %Processor Time CPU

　　Processor%user time 和Processor%Privileged Time

　　systemProcessor Queue Length

　　Context Switches/sec 和%Privileged Time

　　【参考值】：

　　System\%Total processor time不持续超过90%，如果服务器专用于SQLServer，可接受的大上限是80-85% ，合理使用的范围在60%至70%。

　　Processor %Processor Time小于75%

　　systemProcessor 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分析