性能测试工具 Locust 源码阅读及特点思考 (三)

zyanycall · 2018年01月31日 · 最后由 solxnp 回复于 2020年05月28日 · 5 次阅读

这篇想介绍一些我对于 Locust 的一些思考。
目的是:
1.Locust 在日常工作中的地位。
2.如果以 Locust 为基础,搞性能测试,乃至性能测试平台,路还有多远。
以上我会结合着 Jmeter 简单说一下。

github:[https://github.com/locustio/locust]

性能测试工具一般如何实现

1.用例生成

一般两种方式,手写脚本和录制用例。
脚本可以是各种格式各种形式的,比如 HttpRunner 的 YAML,Jmeter 的 jmx/xml,或者 Locust 的 python 代码。
录制用例一般使用抓包工具或者自己内含抓包实现(Pcap4j),抓取网络包(TCP/UDP)再自己解析包内容使其成为可以识别的形式。
用例录制后如果要保存,要保存成指定脚本的样式,这样才能在工具中复用。

用例最好是支持多种协议的,其中 Http(s) 协议,TCP 协议最常用。

2.用例回放

如果回放一次,可以说是接口测试。
如果回放 N 次,可以说是性能测试。
这时需要配置一些性能测试指标如用户数、步长、思考时间等,不多解释。
总体是将一个压力请求复制 N 份,然后在指定时间(步长)内,将这些请求发出去。
Java 的复制,可以是创建多个线程实现。
Locust 的复制,是复制多个用例,放到数组里,然后再弹出去(请求)。

3.结果实时显示

使用绘图工具实现。
一般是一段时间(1 秒或者几百毫秒)间隔的用例回放的某个返回数据的平均值,将其在图上打点,然后之前的点再和这个点连起来。
这个工作一般都是开源的绘图工具实现的。
Locust 的实现是前端的,在 chart.js 中,LocustLineChart,还是比较简陋的。
Jmeter 的可以安装插件显示,也简陋。

除此之外,还需要实时显示错误日志。

4.压力机和服务端性能指标监控

方式很多,可以是 shell 脚本监控,专门的监控软件监控,自己实现的程序监控。
可以是在被压测的服务器端运行客户端程序,将指定的监控指标传给 master 节点,绘图。
或者直接 zabbix 等专业的监控。
服务器端的性能监控还会包含更多,如 pinpoint,CAT 等等较专业的。
Jmeter 也是安装插件实现,简陋。
Locust 就没有。

5.测试报告生成

用例回放的结果,会保存起来,可以保存在内存,文件,NoSQL,数据库中。
文件可以是 csv 格式。
NoSQL 可以是 Redis,Mongodb 等
数据库就太多了,常用是 InfluxDB,MySQL。
然后生成报告时,将这些数据读出来,绘图,加工,成为报告。
Locust 也没有这部分功能。
Jmeter3.0 开始支持报告生成,但是有硬伤。

从上述实现看 Locust 和 Jmeter

1.用例生成

python 脚本是亮点,毕竟代码可以实现一切需求。
但不足之处很明显:
1.util 包没有,复杂用例编写代码工作量很大,维护成本很大,同时考验代码功力。
2.没有录制用例,保存用例功能,即便使用 HttpRunner 支持的录制保存,也只是基础用例。
实际上性能测试刚需的如参数化,还是要手写 python 脚本。
以上对于时间较紧的测试需求,用 Locust 明显是撞墙。

Jmeter 明显好很多,本身 GUI 界面简单明了,各种内置函数帮助你写脚本。
就算用例编写很复杂,还提供了 beanshell,可以使用 Java 代码实现(虽然调试比较费劲)。
同时 Jmeter 拥有各种协议的插件,还是不错的。

2.用例回放

Locust 存在硬伤,因为是 python+ 协程实现,性能很弱。
我自测过,4 个逻辑核的联想笔记本,Locust 使用 4 个 slave,造成的压力是 1.3k,Jmeter 是 13k,差了 10 倍。

3.结果实时显示

Locust 比 Jmeter 更亲切一点,半斤八两。
解释一下为什么说半斤八两。
简单几百几千个请求的情况就不说了,性能测试对压测时间压测的量是有要求的,百万上亿的请求不是事儿。
这时候对压测图形的要求就比较高了,最理想的是可以看到每个细节,不能秘密麻麻的看都看不清,那无法定位问题。

4.压力机和服务端性能指标监控

Locust 压根没有,Jmeter 是有但是和没有差不多。
这个没什么,服务器的性能监控越来越复杂,不好监控。
LoadRunner 的服务器性能指标监控是非常棒的,确实专业。

5.测试报告生成

Locust 压根没有,Jmeter3.0 开始有,并且还可以接受。
Jmeter 报告的硬伤:报告来源于分析日志,日志格式是 csv 的,平均 10000 个请求占用 1MB 的空间。
如果请求数上千万,日志就非常大了,生成报告可以卡死。

测试报告非常重要:
1.有的产品是必须要测试报告的,Locust 直接 PASS。
2.没测试报告文件,很难回复测试结果,不够直观也很容易解释不清楚。

理想的测试报告是最好有结论的,领导最喜欢的就是直观,一句话告诉我性能行不行。
如果有性能截图的话,领导的问题往往非常直接,比如:这里怎么下去了,这里怎么上去了等等,非常便于讨论问题。
如果都是乱糟糟的文字描述,太费劲。

从实现评价 Locust

能用,但不实用。

工作中典型场景看 Locust

领导:测一下这个 http/get 接口,顺便做一下性能测试,压力不用太大。

Locust:先用 postman 测试基本功能,后写 python 脚本压测,参数化实现工作量较大,如果领导突然说压力要大一点儿,Locust 就不行了。
Jmeter:全部使用 Jmeter 测试,根本不用担心压力多大,接口测试的简单边界 Jmeter 也能胜任。

领导:测一下这个页面性能,看看能支撑多少用户/RPS 访问。

Locust:基本抓瞎。

  1. 使用 fiddler/charles 看页面请求,过滤掉静态资源,为每一个请求写脚本(HttpRunner 的录制生成)。
  2. 如果有服务器状态标识如 session/token,或者 postman 额外请求,或者 chrome 开发者工具找到对应内容,手工保存。
  3. 最好没有参数化部分,要不然脚本改动很大。
  4. 请求太多可能会造成压力分配有限,Locust 可能不能胜任。
  5. 如果领导需要加上静态资源,生成脚本动作重新来一遍。

Jmeter:

  1. 自身录制请求,软件内过滤静态资源较方便,每个请求都会录制好,手动操作很少。
  2. 不用额外 postman,Jmeter 自身就胜任各种请求,同时 sesson 内容(id)或者 token 直接使用参数化保存在 Jmeter 内部,少去手工保存动作。
  3. 无所谓参数化,很简单。
  4. 压力足够。
  5. 如果要加静态资源,亮化静态请求即可。 同时,加 http 头信息非常方便。

领导:测试报告导出来看一下。

Locust:what?
Jmeter:稍等,马上。

领导:增加并发,并发不够看不出问题。

Locust:给我几台虚拟机
Jmeter:哦,好的。

Locust 的优势

要改造成 Jmeter 的程度几乎是不可能的,Jmeter 多少人在维护多少人在用,Locust 几个人维护几个人在用,几乎是无底洞。

  • 非 Java 语言说出去好听,
  • 语言特性,工作不需要 Jmeter 那么多的话,开发起来会比较快。
共收到 12 条回复 时间 点赞
zyanycall Locust 源码阅读及特点思考 (二) 中提及了此贴 01月31日 08:25

感觉结果就是还是用 jmeter

恭喜你 撕下了皇帝的新装!😂😂

—— 来自 TesterHome 官方 安卓客户端

郭丽丽 [该话题已被删除] 中提及了此贴 02月03日 13:06

我也是在项目里踩过 locust 的坑,确实是皇帝的新装。

真正的问题还不是上面那些,而是这种单线程使用 event loop 的架构不太适合做压测,除非资源消耗非常低。

当单个核跑到 90%+ 或 100%,event loop 会受影响,这程序记录的响应时间就完全不可信。

我是写完脚本压完才发现响应时间一看就完全不可信,用静态页对比一下,其他工具得出的响应时间<10ms,locust 居然得出 300+ms……

而且它占用资源非常多,这边的服务器是 4 核虚拟机,用 20 以上的 vuser 跑,cpu 单核就到 90%+ 了,结果完全不能看。

而且 locust 的作者在性能方面也不专业,不只一个人提过 issue 说 locust 的性能问题了,他们都认为没问题。我把测试结果提 issue,人家直接关了。

后来用回 jmeter 重做了一遍,白白浪费几天时间,坑死了。

Keith Mo 回复

多谢指点。 你在 issue 上提的问题我看了,Locust 的作者解决不了你提的问题。

10楼 已删除

我自测过,4 个逻辑核的联想笔记本,Locust 使用 4 个 slave,造成的压力是 1.3k,Jmeter 是 13k,差了 10 倍。为什么结果会相差那么大,我这边反而 locust 能跑出更高的 tps

一本正经 回复

locust 默认了 1s 等待时间,min_wait=0,max_wait=0 试试看。

哎 最近也是打算用 locust 做压测的 实验了两天后发现达不到使用标准 作为施压侧 能力太弱了 经过实验最终得出的结论是 单核只能承载 500 左右的 RPS

我 12 核的 CPU 开了 12 个 slave 实际施压 RPS 不到六千 准备去试下 golang 下的 boomer 看看是否能达到作者说的十倍的提升

关于这个生成压力的对比,我也做过,我做过的和楼主恰恰相反,locust 更好。具体还可以参考这个文章。https://blog.csdn.net/Testfan_zhou/article/details/105144332?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1 这个过程很清晰明了,作者可以把自己的测试过程发出来,看看。还有报表问题,既然都用 locust 了,完全可以自己根据数据绘图,这个不难实现。我不是想说 locust 比 jmeter 更好,工具只是工具。只是作为测试来讲,比较较真儿

你逗笑我了……文章作者是你吗…… 好了,我严肃一些。 你的文章结论还行,一些我是赞成的。 爱用 locust 就去用,只不过我不推荐。 论单机的性能发起,去用 webbench。 复杂测试脚本,不嫌累就去用 locust,反正我不用。 逗笑我是因为,你认为 “个人感觉在报表方面,两个工具相差不是很大,都基本能满足工作需求”,有点儿搞笑,你如果能用 locust 实现出来和 Jmeter 性能测试报告相同实力的报表,真的,你就是业界翘楚,我为你单独写一篇,分析你写的源码报告。

solxnp 回复

那么多年过去了,boomer 使用提高你是十倍的能力么。。。。 -___.-

猫星人 回复

反复读了几遍这句话,还是没明白想要表达什么意思

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