性能测试的概念是什么，基本⽬的是什么，我想⼤家都基本清楚，不作详述，总之，性能测试只是测试过程中的⼀种⽅式，帮助我们的功能更好的运⾏，如果功能测试是可⽤，易⽤，满⾜需求、⽤户使⽤为⽬的，性能测试⽆⾮就是让这些⽬的更流畅。没有什么专业的概念，⽆⾮实现两个字：好⽤！
所以，性能测试这种测试⽅式在发⽣过程中，其中⼀个过渡性的⼯作，就是对执⾏过程中的问题，进⾏定位，对功能的定位，对负载的定位，最重要的，当然就是问题中说的“瓶颈”，接触性能测试不深，更⾮专家，⾃⼰的理解，瓶颈产⽣在以下⼏⽅⾯：
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
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⽅式了.
Average Transaciton Response Time(事务平均响应时间)随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应⽤系统随着投产时间的变化，整体性能将会有下降的趋势
Transactions per Second(每秒通过事务数/TPS)当压⼒加⼤时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈
Hits per Second(每秒点击次数)通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进⼀步分析，发现系统瓶颈所在。
Throughput(吞吐率)可以依据服务器的吞吐量来评估虚拟⽤户产⽣的负载量，以及看出服务器在流量⽅⾯的处理能⼒以及是否存在瓶颈。
Connections(连接数)当连接数到达稳定状态⽽事务响应时间迅速增⼤时，添加连接可以使性能得到极⼤提⾼(事务响应时间将降低)果蔬包装机
Time to First Buffer Breakdown(Over Time)(第⼀次缓冲时间细分(随时间变化))可以使⽤该图确定场景或会话步骤运⾏期间服务器或⽹络出现问题的时间。
碰到过的性能问题：
1. 在⾼并发的情况下，产⽣的处理失败(⽐如：数据库连接池过低，服务器连接数超过上限，数据库锁控制考虑不⾜等)
2. 内存泄露(⽐如：在长时间运⾏下，内存没有正常释放，发⽣宕机等)
3. CPU使⽤偏离(⽐如：⾼并发导致CPU使⽤率过⾼)超低温真空浓缩设备
4. ⽇志打印过多，服务器⽆硬盘空间
如何定位这些性能问题：
1. 查看系统⽇志，⽇志是定位问题的不⼆法宝，如果⽇志记录的全⾯，很容易通过⽇志发现问题。
⽐如，系统宕机时，系统⽇志打印了某⽅法执⾏时抛出out of memory的错误，我们就可以顺藤摸⽠，很快定位到导致内存溢出的问题在哪⾥。
有一个t形工件
2. 利⽤性能监控⼯具，⽐如：JAVA开发B/S结构的项⽬，可以通过JDK⾃带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole 可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。
利⽤Spotlight可以监控数据库使⽤情况。
我们需要关注的性能点有：CPU负载，内存使⽤率，⽹络I/O等
3. ⼯具和⽇志只是⼿段，除此之外，还需要设计合理的性能测试场景
具体场景有：性能测试，负载测试，压⼒测试，稳定性测试，浪涌测试等
好的测试场景，能更加快速的发现瓶颈，定位瓶颈电能量采集终端
4. 了解系统参数配置，可以进⾏后期的性能调优
除此以外，还想说个题外话，就是关于性能测试⼯具的使⽤问题
在刚开始⽤Loadrunner和JMeter的时候，做⾼并发测试时，都出现过没有把服务器压垮，这两个程序⾃⼰先倒下的情况。
如果遇到这个问题，可以通过远程调⽤多个客户端的服务，分散性能测试⼯具客户端的压⼒来解决。
说这个的⽬的是想说，做性能测试的时候，我们⼀定要确保瓶颈不要发⽣在我们⾃⼰的测试脚本和测试⼯具上。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议