协议级性能测试学习笔记（1）

一、概念：

负载测试：  关注在不同用户数量，响应的系统它的性能反应，性能指标；

压力测试：  关注高压力，很大的用户同时去访问给服务器施加压力，系统是怎么死的；

容量测试：  最大支撑的数量（用户的数量、数据库）

二、性能评价指标：

响应时间：从用户的角度评价系统的处理速度（2-5-10）；

吞吐量：硬盘IO、网络IO、CUP内存、请求处理能力、打开页面数量；

事务处理能力-TPS : 处理当事务的能力、综合处理事务的能力；

三、性能测试关注点:

响应时间

服务器端资源：

数据库端的资源使用情况：

最大访问用户数量

最大业务处理数量（核心业务）

系统能否支撑7*24小时运转

内存资源，线程资源能否正常回收

代码：算法、SQL 语句

稳定性，可恢复性怎么样？

四、性能测试核心原理：

基于协议:网络分布式架构

多线程:模拟用户负载

模拟真实场景：

到底并发多少虚拟用户是合理的？

1、从TPS业务量来看（在已经评估的系统上做一点增加）；

2、通过Ramp Up来做预测试，通过慢慢增加来看系统的监控服务器的指标，最近服务器的最佳指标数量值，来确定并发的最大用户并发数量；来看能不能达到需求的TPS业务量。

3、针对新系统通过Ramp Up来确定并发的最大用户并发数量，等系统正式运营后去监控最大用户数和服务器的指标，一旦接近最大并发数量，想办法来优化系统。

五、性能测试场景设计

1、针对Phpwind 的基本性能测试设计：

a）每一个线程的每一次循环，均独立完成：首页—登录—发帖—回帖—点赞—搜索—退出，本场景方案没有什么特殊性可言，所有线程完成同样的工作。（混合场景）

b）每一个线程，只登录一次，然后每一次循环，只完成发帖的功能，每一个线程，最后退出。

针对特定场景进行设计（仅发帖功能），但是需要有前提，收尾。（单一场景）

c）不同的线程，做事情为什么要完全一样？不符合真实情况，随机场景。不同的用户，执行的操作并不完全一样。（随机场景）

2、如何模拟真实场景

a)门型场景：并发用户数突然间从0变成N，持续一段时间，又从N变成0。（适应于压力测试，目的在于检测服务器的抗压能力，如果无法抗住压力，服务器表现出来的反应）

b)拱型场景：并发用户数慢慢从0变成N，整个过程具备节奏感，可监控跟踪该段时间内，随着并发用户数的增加（Ramp Up），相关性能指标到的变化趋势。与之对应的，从N变成0的过程（Ramp Dowm），也应该如此。（适用于负载测试，也适用于指标分析，以及系统性能预测试）

c)复杂场景：模拟真实服务器访问情况，不停的在Ramp Up , Duration , Ramp Dowm 之间切换，场景运行图像类似于高低起伏不同的波浪线，这类场景运用较少，因为需要大量的历史数据作为支撑，通常不适用于对未上线的系统进行设计。

d)混合场景：综合利用上述各类场景，进而更好的模拟真实情况，比较理想的一种模型，真实价值不大。但在LR 这款工具中，对混合场景也进行了另外的解释，就是将多个性能测试脚本混合在一起同时运行。

3、关于场景设计

脚本代码

脚本结构

并发设置

持续优化（先做一些预测试如登录响应时间、发帖、回帖、点赞等时间，然后在Ramp Up 的时候就可以知道运行5到10次大概需要花费多长时间）

4、场景在脚本层面设计:

每10秒增加5个线程，50个线程，需要100秒增加完成。

究竟多长的时间间隔用于完成Ramp Up 的过程？Ramp Up 的过程是为监控不同负载情况下的性能指标的变化趋势，所以，一定要确保时间间隔是足够的，最好让每一批Ramp Up增长的线程能够多运行一会儿，至少确保运行5-10次。那么，5-10次大概要花费多少时间？根据响应时间的长短来决定。

六、指标分析的方法：

1、Runing Vusers—AverageTransation Response Time

关联随着50虚拟用户数量的增加，平均响应时间不受影响，正常运行。

关联随着100虚拟用户数量的增加，到55个用户时响应时间开始增加，出现55个以后就可能导致系统出现瓶颈了。

2、Runing Vusers— Windows Resources

随着50虚拟用户数量的增加，CPU也在逐渐增减，最大值达到87%；

随着100虚拟用户数量的增加，CPU也在逐渐增减，当虚拟用户增加到70个，CPU达到100%；当结束的时候用户到达60个，CPU达到100%；

内容学习来源邓强老师的协议级性能测试自动化。