一、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