一、Processor
①%processor time
- %processor time:指系统执行非空闲时间的百分比。
- 阈值（ 正常范围）：对于一个系统而言，%processor time的平均值小于85%，则没有问题。如果其平均值超过85%或者其值持续超过95%，则怀疑处理器瓶颈
- 对于阈值，不同的公司可能有不同的要求，即使同一公司，可能也会因为项目不同要区别对待，一般情况，小于75%到85%都视为正常。
如果%processor time图中偶尔走高，达到100%，要看其平均值，一般没有问题。
②Processor queue length
性能测试过程中，双核处理器一般视为2个CPU
处理器队列的阈值是：≤n+1,其中n是处理器个数
二、Memory
MemoryAvailable MBytes(可用物理内存值，单位是M)：如果windows系统中可用内存小于物理内存总数的1%，则内存可能是瓶颈。
- 系统可以在内存中存在大量软错误的情况下，正常运行。但是如果系统存在大量的应错误，则会严重影响系统的性能。一般来讲，硬错误（单位是个数）的阈值为是内存的1%，即2G，硬错误不要超过20个。
- 如果pages/sec或者Page reads/sec（页面的读取率）值很高，则有可能内存不足。
三、System
系统吞吐量指的是系统在单位时间内可处理的事务的数量，是用于衡量系统性能的重要指标。
四、Physical Disk
性能调优的一个原则：尽量减少磁盘IO。因为如果很大，会严重影响系统的性能。
Disk Read(Write)bytes/sec:如果该值超过几十M，甚至上百M，则怀疑磁盘瓶颈。
五、Network Interface
- Byte total/sec的阈值：该值*8后再与带宽的一半进行比较，如果小于带宽的一半，则一般认为网络没有瓶颈。带宽的单位为bits
六、实例分析
系统中硬件的瓶颈比软件瓶颈容易解决（更换硬件），但是大部分的情况，都不是硬件问题，都表现为硬件的问题，但实际上瓶颈是由软件引起的，如程序代码，SQL语句等等。比如没有建立索引，需要全表扫描
①处理器分析
- %processor time平均值大于95
- processor queue length大于2+1
- 通过CPU表现可以确定该过程中存在瓶颈，此时的CPU已经不能满足程序要求，可能需要扩展。
②判断内存泄漏问题
- 图中可以看到该程序并不存在内存泄漏的问题
- 内存泄漏问题经常出现在服务器长时间工作的时候，由于部分程序对内存没有释放，而将内存慢慢耗尽。也是提醒大家对系统稳定性测试的关注。
③应用程序
- context switchs/sec变化不大
- throughout曲线整体斜率不高
- 并且此股从而航context switches/sec已经超过了15000
- 程序需要进一步优化
应用服务器参数设置：
- 一般情况下，服务器的默认设置都比较低，当开发人员疏忽此问题时，有可能报错，如连接池超过最大连接数时，则对继续连接的用户会报错，拒绝连接。此时，将连接池中连接数调大即可。
- 调整参数时，最好单独调整，除非是有关联关系的数据；并且在调整时，要每次增加一部分，如50%左右，不要调整太大，逐步达到最优的效果，提升性能。
- 当系统的参数调整后，寂静录制好的脚本是否需要重录脚本？—不需要，因为业务逻辑没有变化。只需要重新运行场景即可。
调优过程：调整某个参数–>运行场景–>调整某个参数—>运行场景….直到报告结果中性能有所提升
查看并
查看并发的出错规律某系统50并发，失败9个
- 100用户并发，失败59个
- 150用户并发，失败109个
因为系统只支持上一次成功并发用户数，如果上一次是25用户并发，则系统支持25个用户并发
为什么不是支持41并发？因为41个用户并发不是在正常环境下并发得到的，而是50用户并发失败的结果，不准确
④监控指标数据分析
图形在Graphs—>Add New Item—>Add New Graph—>Web Resources—>Connections、Connections Per Second
