业务系统性能压测的最佳实践
压测工具的选择
目前主流的压测工具有
- ab
- Jmeter
-
阿里云PTS
如何来选择呢,我们建议如果是简单压测,可以直接使用ab来进行,它可以通过一条命令来快速的发起指定并发数的请求。但如果需要进行复杂的压测,建议使用后两者:
Jmeter是开源的压测工具,可以实现非常复杂的压测需求,比如设定一个包含很多URL的场景、配置一个施压集群来发起压测测试等等,而阿里云PTS服务,相较于Jmeter增加了许多独特的功能,比如:
- 施压流量来自真实CDN节点,最大限度模拟真实流量的路径
- 纯SaaS,无需额外安装和部署
- 兼容Jmeter脚本,可以平滑的复用之前的jmx脚本文件
- 配置界面所见即所得,对于新手非常友好
所以,我们建议大家根据实际的压测需求来选择压测工具。另外,如果您对PTS感兴趣,可以前往PTS控制台进一步了解。
阿里云上业务压测流程上的注意事项
施压前
- 对业务系统容量有一个预估,比如QPS、并发用户量
- 确定好压测时间和压测环境,尽量不要直接对生产环境压测,避免影响业务
- 若链路上存在SLB,建议至少使用4台施压机来压测,施压机越多,SLB的转发会越均衡
- 合理安排施压机的压测能力,若单台施压机无法满足施压需求,可以构建Jmeter施压集群或者使用PTS进行压测
-
若链路上存在安全模块,如高防、Web应用防火墙等,建议对施压机的源IP添加白名单,避免施压机被安全模块拦截
施压中
- 密切关注被压测的模块的各项监控
-
当出现瓶颈时就可以考虑停止或延迟若干分钟停止压测,避免产生无效的压测流量
施压后
- 结合业务数据对施压结果进行分析,确定系统是否可以达到预期的目标
- 出现瓶颈后,需要及时优化业务程序
压测结果相关
如何判断目标系统是否出现瓶颈?
判断瓶颈的方法非常多,比较简单的方法之一是增加并发用户数量,查看目标系统的TPS是否同步上涨,如果没有出现增加,甚至出现了下降,说明业务系统处理每个请求的时间变长,可以近似理解为此时的业务系统就出现了瓶颈。
并发用户、RPS、TPS如何解读
名词的定义千差万别,但归根结底的形容都是类似的,以下可以作参考:
并发用户:施压机上同时去请求的用户数量,比如500个并发用户,配置的施压目标是串行的两个URL,那么施压过程中,就会有500个客户端,不停地去请求URL 1和URL 2,用户之间的请求互不影响,并发的请求,而每个用户是先请求URL 1,得到结果后在请求URL 2,得到结果后再循环请求URL 1,以此类推。
RPS:在PTS中,RPS被定义为施压机每秒发出的请求数
TPS:在PTS中,TPS被定义为压测目标每秒执行的事物数,若目标系统是基于HTTP(S),可以理解为每秒能够执行多少HTTP请求。
那么有的同学会问了,TPS和RPS有什么差别呢?在正常情况下,RPS的数值近似等同于TPS,TPS对于一个系统来说,是恒定的,但只要施压机性能还够,RPS还可以提升,只是此时目标系统已经无法处理,可能会出现连接失败、请求超时等异常的响应,那么此时,RPS是大于TPS的,需要及时停止施压并分析目标系统为何会出现异常
原文链接
本文为云栖社区原创内容,未经允许不得转载。