性能测试工具-Locust

前言:工作中需要进行压测两个接口,在技术选型上,主要对比jmeter和locust两个压测工具,最终选择用locust进行压测,本文主要记录下本次压测工作对于性能测试的初步了解,和工作过程中对locust工具的学习和使用。

目录

一、需求分析

1、支持10万用户的并发?

2、什么是并发

3、不同的并发机制

​编辑4、性能测试关键指标

4.1、吞吐量

4.2、响应时间

4.3、资源利用率

4.3.1、CPU使用率

4.3.2、平均负载

4.3.3、CPU使用率和平均负载的关系

5、性能监控平台

5.1、prometheus工作原理

5.2、mac上部署prometheus

6、性能测试负载模型

二、压测工具对比与选择

1、Jmeter VS Locust

2、locust单机并发能力

3、jmeter单机并发能力

三、locust主要类/方法介绍

1、HttpUser vs FastHttpUser 

2、TaskSet vs SequentialTaskSet

3、task装饰器作用

4、beteen的作用


首先分为三个部分:需求分析、压测工具对比与选择、locust类/方法

一、需求分析

1、支持10万用户的并发?

本次压测,要求压测两个接口(一个注册接口、一个数据上报接口),支持10万用户的并发

需求很简单,先拆解需求,是真的有10万个用户同时请求服务器的这两个接口?是这样的并发吗?显然不是,这10万个请求要在一段时间内发出去,那这一段时间是多少?是一分钟将10万个请求发出去?如果是1分钟,那每秒处理就要处理大约1666个请求,QPS要达到千级别。

基于上面的分析,我们先来看下并发的概念

2、什么是并发

看并发之前,先来看一个相似的名次:并行,并行是指同一时间点,任务同时地运行,比如一台电脑,有8个CPU,每个CPU的每个核心都可以独立地执行一个任务,在同一时间点,可同时执行8个任务,这时任务是同时执行,并行地运行任务。

并发则是指,同一时间点,只能去执行一个任务,只不过任务之间快速切换,使得看上去像是多个任务在同时运行,但实际并非如此。

并发可以发生在不同进程之间,不同进程的切换,也可以发生在同一进程,不同线程间相互切换,还可以发生在同一线程内,不同协程间相互切换。

3、不同的并发机制

针对这几种并发的机制,下面将对比其优缺点。

不同并发机制的优缺点对比如以下图表,可以看到最轻量级的是协程,适用于单线程处理高并发的场景,针对CPU密集计算型,适用进程,针对IO密集型任务,适用线程。

4、性能测试关键指标

性能测试关注的指标都有哪些?一般的测试工具都会给出压测时系统的响应时间、吞吐量。

4.1、吞吐量

吞吐量是指每秒系统能处理的事物数量,重点是能处理多少。

4.2、响应时间

响应时间是指在多少时间内处理完,重点是有多快

所以要同时关注处理事物的多少(吞吐量)和速度(响应时间)

4.3、资源利用率

此外,还要关注资源利用率,压力机的CPU利用率在多少?内存/磁盘剩余多少?网络带宽多少,这些资源利用率都会影响到最终的压测指标,也要重点关注。

资源利用率,这里我们再主要关注两个:CPU使用率,平均负载

4.3.1、CPU使用率

CPU 使用率就是 CPU 非空闲态运行的时间占比,它反映了 CPU 的繁忙程度。

4.3.2、平均负载

平均负载(Load Average)是指单位时间内,系统处于 可运行状态(Running / Runnable) 和 不可中断态 的平均进程数,也就是 平均活跃进程数。
可运行态进程包括正在使用 CPU 或者等待 CPU 的进程;不可中断态进程是指处于内核态关键流程中的进程,并且该流程不可被打断。比如当进程向磁盘写数据时,如果被打断,就可能出现磁盘数据与进程数据不一致。不可中断态,本质上是系统对进程和硬件设备的一种保护机制。

简单点理解就是,CPU使用率就是在使用时,CPU真正做事时的繁忙程度,平均负载就是在排队等待的进程数量。

4.3.3、CPU使用率和平均负载的关系

是不是CPU使用率高,平均负载也会很高?它们之间有什么关系?

针对CPU 密集型应用,大量进程在等待或使用 CPU,此时 CPU 使用率与平均负载呈正相关状态。I/O 密集型应用,大量进程在等待 I/O,此时平均负载会升高,但 CPU 使用率不一定很高。

5、性能监控平台

后端数据监控平台:普罗米修斯(prometheus)

5.1、prometheus工作原理

收集数据用到node_exporter(监控操作系统),展示数据用到grafana

5.2、mac上部署prometheus

具体在mac上如何配置,请移步:

Mac上部署prometheus_MRJJ_9的博客-CSDN博客

如下图,配置完成后各项指标的监控图表展示

6、性能测试负载模型

下面介绍,性能测试负载模型,随着压力不断增加,指标值也是不断变化的。

压测时,只关注吞吐量,或者响应时间,都是不全面的,需要同时关注三项关键指标。

首先看吞吐量,刚开始加压时,吞吐量是不断增加的,后面随着压力越来越大,吞吐量反而下降了,此时说明已经到了系统的极限;

再看响应时间,在出现拐点以前,随着压力的增加,响应时间没什么大的变化,等到达到一定的点,响应时间不断增加,此时说明已经到了系统的极限;

最后,资源利用率,逐渐加压过程中,是不断提高的,等达到一定的用户数,系统的资源利用率达到最大,只能利用到这个程度,无论再加多大压力,也不会再提高。

需要关注两个点:最佳的并发用户数、最大并发用户数,系统最大能支持多少并发,测的就是这个拐点区的值,最大并发用户数是多少?

二、压测工具对比与选择

主要对比几种主流的测试工具:Jmeter、loadrunner、locust、apachebench

1、Jmeter VS Locust

因为Loadrunner是收费的,apachebench不支持场景压测

下面主要对比下Jmeter和locust

2、locust单机并发能力

设置不同的虚拟用户数,以下为笔者当时跑的数据记录 

设置不同的每秒启动用户数, 以下为笔者当时跑的数据记录 

3、jmeter单机并发能力

TPS在260左右,响应时间在1800ms左右 

可以看到,Locust单机并发能力比Jmeter要更高,故本次压测选用Locust工具。

三、locust主要类/方法介绍

1、HttpUser vs FastHttpUser 

笔者曾针对一个接口,同样的设置,同样的时间,分别用这两个类测试过,测试的结果为:使用HttpUser, FPS跑到80左右,平均响应时间在7000ms左右,CPU利用率也明显上不去,使用FastHttpUser,FPS可以跑到600左右,平均响应时间在800ms左右。

locust压测时,两种脚本编写方式

第一种如下,将任务(需要压测的接口)放到类的里面

from locust import task, between,FastHttpUser
class WebUser(FastHttpUser):
    host = "host_all"
    wait_time = between(3, 5)

    @task(1)
    def info(self):
        self.client.get("url1", headers=header, cookies=cookie)

    @task(3)
    def report_total(self):
        data = {"data1": 'test1', "data2": 'test2'}
        self.client.get("url2", params=data, headers=header, cookies=cookie)

第二种如下,类里继承TaskSet任务集

2、TaskSet vs SequentialTaskSet

使用Taskset,接口api_1和api_2不是按顺序调用的,随机调用。

from locust import task, TaskSet, between,FastHttpUser
class Tasks(TaskSet):
    wait_time = between(3, 5)

    @task(1)
    def api_1(self):
        self.client.get("url1", headers=header, cookies=cookie)

    @task(3)
    def api_2(self):
        data = {"data1": 'test1', "data2": 'test2'}
        self.client.get("url2", params=data, headers=header, cookies=cookie)

class WebUser(FastHttpUser):
    host = "host_all"

使用SequentialTaskSet,按顺序调用接口,比如下面的例子,每调用完一次info接口,调用三次report_total接口。

from locust import FastHttpUser, task, SequentialTaskSet, between
class Tasks(SequentialTaskSet):
    wait_time = between(3, 5)

    @task(1)
    def info(self):
        with self.client.get("url1", headers=header, cookies=cookie) as res:
            data = json.loads(res.text)
            datas = data.get('data')
            data_all = []
            for i in range(0, len(datas)):
                data_all.append(data_all[i]['test'])
            self.data_all = data_all

    @task(3)
    def report_total(self):
        for every_data in self.data_all:
            data = {"data1": every_data, "data2": "test2"}
            self.client.get("url2", params=data, headers=header, cookies=cookie)

3、task装饰器作用

如上图,task后面带(1),(3),表示执行任务的权重,比如一共发了400次请求,分到权重为1的接口,大概为100次左右,分到权重为3的接口,大概为300次左右。没有标记数字,则默认执行任务权重1:1

4、between的作用

设置等待时间,模拟真实用户操作,实际测试过程中可减少压力。

  • 6
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

MRJJ_9

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值