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