一.资源指标分析

1.判断CPU是否瓶颈的方法

一般情况下CPU满负荷工作，有时候并不能判定为CPU出现瓶颈。比如Linux总是让CPU尽可能最大化使用。
判断CPU瓶颈的条件：CPU空闲持续为0 ；运行队列大于CPU核数（经验值3——4倍）
造成瓶颈的因素：应用程序不合理，硬件资源不足。比如SQL语句引起，则要优化CPU使用过高的SQL语句。

2.判断内存是否瓶颈的方法

一般至少有10%可用内存，内存使用率可接受上限85%。空闲内存过小可能是内存不足或内存泄漏引起的。

3.判断磁盘I/O是否瓶颈的方法

（1）计算每磁盘I/O数。

RAID类型	计算方法
RAID 0	(Reads+Writes)/Numbers of Disks
RAID 1	(Reads+2*Writes)/2
RAID 5	[Reads+(4*Writes)]/Numbers of Disks
RAID 10	[Reads+(2*Writes)]/Numbers of Disks

经过计算得到的每磁盘I/O数超过磁盘标称的I/O能力，则说明存在磁盘的性能瓶颈。
（2）监控磁盘的读/写。如果磁盘长时间进行大数据量读/写操作，且CPU等待超过20%，则说明磁盘I/O存在问题，考虑提高磁盘I/O读/写性能。

4.判断网络带宽是否是瓶颈的方法

通过减小网络带宽，查看并发用户数，响应时间与事务通过率等性能指标是否不能接受。反之，增加网络带宽，性能指标是否明显提高。
如果性能测试始终报连接超时，实际手工访问正常，可以用ping命令查看网络是否同，如果出现网络严重延迟或丢包，则说明网络不稳定。

二.系统指标分析

1.平均响应时间
如果持续并发性能测试，监控平均响应时间逐渐变长，这时需要借助监控到的资源指标，首先排除资源方面的限制元素，再从应用本身进行定位。
2.并发用户数
一般选用高吞吐量，高数据I/O，高商业风险的业务功能进行并发用户访问测试。
3.事务成功率，超时出错率
4.吞吐量
吞吐量通常由QPS（TPS）和并发数两个因素决定。
QPS（TPS）= 并发数/平均响应时间

三.性能调优

性能优化策略：用空间换时间，用时间换空间，简化代码，并行处理。

总结：性能指标是要结合分析的，这种指标都是相关联的，性能调优也是有多方面调优，需要对数据库，算法，网络，代码熟悉，根据积累的经验进行调优。

四.性能测试案例

1.项目背景

2.实施规划

（1）需求分析

• 新版本上线前
  一般直接在生产环境上进行性能测试，进行压力测试，配置测试。
  测试目标：验证系统在饱和负荷下的业务处理能力；发现系统瓶颈并通过相关参数调优，提高整体系统处理能力。

• 新需求版本上线前
  一般在测试环境进行性能测试，进行基准测试。
  测试目标：测试整体系统修改前后监控指标的变化；测试新需求是否达到预定的性能指标。

• 页面测试
  侧重于测试关键业务的整体性能，例如登录，开户，变更等常用业务模块。
  在页面上录制登录，业务操作，受理提交，退出系统的全流程，然后添加验证点，处理关联信息，精简脚本。

• 接口测试
  侧重抽取底层，业务量大，响应时间要求高的业务模块测试，比如查询，业务开通类接口。
  检查环境，检验报文，准备测试数据。

（2）测试方案

1.测试目标：新需求是否满足设计预期，改造需求是否有性能下降。

场景类型	业务模块	接口编号	场景描述	性能指标
接口	指标查询	43543	尝试不同并发下的接口调用，在TPS达到指标要求时，验证响应时间是否达标	TPS>=6;平均响应时间<=3000ms
页面	群组套餐变更	无	尝试不同并发下测试新旧版本，在TPS达到指标要求时，检验响应时间是否下降>=5%	新版本较旧版本的响应时间是否下降>=5%

2.测试环境：环境性能差异，中间件的参数配置都需要记录。硬件基本信息，中间件参数配置，数据库。
3.测试场景：初步确定一个业务的并发场景，比如5并发，10并发，20并发。

序号	业务名称	业务指标	性能指标
1	套餐变更	TPS>=6,平均响应时间<3000ms	CPU <=85%,内存空闲率为80%，磁盘I/O没有出现分页现象
2	添加成员	TPS>=12,平均响应时间<3000ms	CPU <=85%,内存空闲率为80%，磁盘I/O没有出现分页现象

4.测试数据
5.职责分工
6.测试环境准备
7.测试工具

软件名称	说明
Load Runner	性能测试工具
soapUI	接口功能调试工具
HttpWatch	页面连接加载测试工具
Nmon	主机资源监控工具

3.性能测试执行

1.录制脚本，录制接口
2…测试策略
3.监控

4.结果分析