性能优化之几种常见压测模型及优缺点

转载：https://blog.51cto.com/u_15127580/2732934

压测模型抽象

 

 

 

可以把压测模型抽象为上图的模型。

 

压测环境准备

压力机资源

被压测系统

依赖资源（压测数据，第三方依赖）

 

压测策略准备

压测需要达到的目标（比如期望达到的QPS，稳定性要求等）

压测场景（业务场景选取、组合）

压测策略（逐步加压、脉冲、并发量等）

 

压测执行闭环

压力机压测

分析程序收集压测数据（RT，QPS/TPS，成功率，错误，内存，IO等）专业的工具基本涵盖

分析压测报告

确定优化计划

反馈到压测系统或者调整压测策略

 

线下压测模型

 

 

 

 

 

此类压测模型最多，也是最容易实现的。有技术实力、资源的公司，开发环境和压测环境是隔离的。

 

图中举例的是分布式系统结构的压测拓扑图，实线是同步调用，虚线是消息类调用。

 

此类压测方式，最容易操作，有如下优点：

可以实现快速压测

压测场景可以自由自定

可以进行稳定性测试或者链路性性能回归

 

但是从执行来看缺点也很多

仿真度不高

环境部署复杂

多个压测任务一般不能并行

 

环境问题永远困扰你

比如仿真度问题，环境问题永远困扰你

依赖系统可能缺失

数据可能确实

使用的机器，网络，DB都和线上不一样。

服务化后，线上各应用是集群部署，比如A可能是1000台，B可能是100台，是10：1的比例关系，但是线下一般是1：1，这个比例是失真的。

 

线上引流压测模型

 

 

 

此类压测模式是使用比较多的高仿真压测。

 

有如下优点：

真是的业务场景测试

可以按需缩容

可以快速回退

 

缺点也有：

对链路节点压测不了（DB流量可能不够，网络节点等）

很难进行超出业务流量的压测

很难评估链路性能

 

线上引流压测是不错的压测模式，关键技术有

流量的控制能力

可以按需切换流量，web层诸如使用ngnix，服务和服务调用之间也需要按需切换。如果为了是自己对流量控制能力更强，都建议在需要控制的各层，加入代理层，这个代理层可以实现路由算法，通过调整路由算法，到达控制的目的。比如可以扩展ngnix的模块，如果是dubbo，可以扩展服务调用的寻址逻辑。

服务监控能力

如何在线上压测快速识别压测情况，如果压测是单台机器，登陆一台机器当然可以确认情况，但是如果有一堆机器，怎么办？必须自动化掉，监控核心指标。

 

服务化后的系统使用普通的线上压测模式很难发现链路问题，所以现在有如下进阶的压测模式，外部也应该分享过。

 

线上全链路压测模式

 

 

 

 

现在阿里体系，已经实现了此类压测模式，用于对大促等爆发流量进行模拟。使用完全真实的线上环境，进行高仿真的线上压测，可以按照线上真实的容量部署情况进行链路压测。

 

优点：

高仿真

按需的压测流量（可以构造比日常容量大得多的请求量）

 

缺点：

实施成本很高，一般的公司可以不这么玩，前面的方式已经够了。

 

其他

这几种模式主要就是现在使用的模式了，可能有变体，我想不会差的太大。

压测的时候还有些注意点，诸如小心压力机的瓶颈；现在使用的比较多的工具是jmeter等。这些就不详解了。
-----------------------------------
©著作权归作者所有：来自51CTO博客作者mob604756f2dcb4的原创作品，请联系作者获取转载授权，否则将追究法律责任
性能优化之几种常见压测模型及优缺点|小丘
https://blog.51cto.com/u_15127580/2732934