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

zyanycall · January 31, 2018 · Last by solxnp replied at September 07, 2019 · 4867 hits

这篇想介绍一些我对于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那么多的话,开发起来会比较快。
共收到 8 条回复 时间 点赞
zyanycall Locust 源码阅读及特点思考 (二) 中提及了此贴 31 Jan 16:25

感觉结果就是还是用jmeter

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

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

郭丽丽 线下班第二期 Bash 教程 中提及了此贴 03 Feb 21: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的作者解决不了你提的问题。

10Floor has been deleted

我自测过,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看看是否能达到作者说的十倍的提升

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up