移动测试开发 服务端压力测试分享

opentest-oper@360.cn · 2019年10月18日 · 最后由 liuau86 回复于 2019年10月20日 · 4809 次阅读

一.压测的目的

压力测试是对系统不断施加压力,来获得系统最大服务能力的测试。
一般而言,只有在系统基础功能测试验证完成、系统趋于稳定的情况下,才会进行压力测试。

目的:
1.当负载逐渐增加时,观察系统各项性能指标的变化情况是否有异常
2.发现系统的性能短板,进行针对性的性能优化
(如:使用 mysql 存储的系统,高并发情况下,数据库读写速度慢,可以考虑增加数据库中间件,加缓存等;使用 redis 存储的系统,通常存储不会制约性能,但在高并发情况下,Redis 的吞吐量非常大,这时候就需要考虑增加网络带宽来提高性能。)
3.系统在高并发情况下是否会报错,进程是否会挂掉
4.测试在系统某个方面达到瓶颈时,系统可以支持的最大负载

二.压测的关注点

压测的指标通常有 tps、响应时间、错误率等,服务器资源监控 cpu、内存、 I/O。
指标的来源:用户对各项指标提出明确需求,如果用户没有提出性能指标则根据用户需求和自己的经验来预估
观察服务器的各种异常情况
1、响应变慢
2、返回 4XX、5XX 错误码
3、服务器无响应
4、服务器 crash 等

三.压测指标


注:并发用户数≠每秒请求数
比如说:在性能测试工具或者脚本中设置了 100 并发用户数后,并不是每秒 100 个请求发给服务器。每秒发出多少请求只跟服务器返回响应的速度有关。如果用户在 50ms 内就收到了响应,那么它会立即发出第二个请求;而如果要一直等待 3 秒才能得到响应,它将会一直等到收到响应后才发出第二个请求。所以,只有当响应时间恰好是 1 秒时,并发用户数才会等于每秒请求数;否则每秒请求数可能大于并发用户数或小于并发用户数。
各项指标关系曲线

在并发数达到一定的数量后,系统的吞吐量就上不去了,如果压力继续增大,系统的吞吐量反而会下降,原因是系统超负荷工作,上下文切换、内存等其它消耗导致性能下降。

四.压测步骤


1.参数化是使用指定数据源中的值来替换脚本中的参数,可以更加真实的模拟现实应用。
2.压测中的场景可以理解为功能测试中的用例,合理的场景设计才会更好地发现系统的性能缺陷。
3.执行压测场景后,若分析结果没有达到预期,提出优化方案,优化后再重新测试。

五.场景设计涉及要素


1.并发用户数是多少?
2.需要包含哪些接口请求,各个接口请求的占比是多少?比如,70% 的用户在请求获取配置的接口,30% 的用户在请求上报结果接口。
3.各个操作之间的等待时间是多少?
4.测试刚开始时,以什么样的速率来添加并发用户?比如,每秒增加 5 个并发用户。
5.测试结束时,以什么样的速率来减少并发用户?比如,每秒减少 5 个并发用户。
6.达到最大并发用户数后持续多长时间?
7.需要监控哪些被测服务器的哪些指标?
8.脚本出错时的处理方式是什么?比如,错误率达到 10% 时,自动停止该脚本。
9.需要使用多少台施压机才能使被压机器产生足够的压力?

六.场景设计分析实例

1000 台客户机,每台客户机间隔 2s 上报一次心跳(获取任务),服务端每秒向每个客户端下发一个任务,每个任务执行完成后向服务端上报 result 和 message。
服务器:lvs 6 台 4 核 8G Linux
数据库:redis、mysql
场景分析:共包含 3 个接口


预估 tps:500+1000+1000=2500 服务器每秒应能支持 2500 个请求
TPS=并发数/响应时间

接口平均响应时间:(100*1+150*2+400*2)/5=160ms
并发数:400
操作顺序:心跳(获取任务)->上报结果 ->上报其他信息
需要监控信息:服务器资源:CPU、内存、负载
数据库:mysql 行锁时间、连接数、从库延时 redis 连接数、CPU 使用率、内存

测试结果分析 - 确认问题
将测试结果与用户需求做比较,如果达不到用户需求,则需要对问题进行分析

七.常见问题分析


优化前:平均响应时间较长,Tps 基本在 1000 左右,由于 mysql 操作占用较高的 io,CPU 大部分空闲,负载均在 1 左右
原因:mysql 的性能影响了服务的性能,由于 mysql 经常连到上海、深圳,所以会时慢时快。
优化:mysql 都连到北京机房
优化后:tps 达到 2000 左右,平均响应时间是优化前的二分之一,tps 是优化前的二倍。

八.压测工具介绍


Jmeter 脚本创建

http 头信息

http 请求

参数化数据文件

BeanShell PreProcessor 是一个前置处理器,它可以进行一些处理,比如执行一个算法并将结果存储到参数中。

响应断言:不符合断言的记为错误请求

设置压测任务的并发数、执行时间等

若未指定 ramp-up period ,默认为零,将立即建立所有线程。假设 ramp-up period 设置成 T 秒, 全部线程数设置成 N 个, 将每隔 T/N 秒建立一个线程。
比如:使用 10 个线程,ramp-up period 是 100 秒,每个线程会在上一个线程启动后 10 秒(100/10)启动

查看聚合报告



Locust 脚本

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 4 条回复 时间 点赞

感觉 locuat 的不准,后台数据库有问题时,jmeter 实际只有一二十的时候,locust 还是有五百多,跟数据库没报错之前差不多

马克,留爪。。。

还有一个问题就是你压测的是线上环境还是测试环境呢?

楼主用这两个工具压测结果有比较吗,哪个感觉更准确呢?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册