这篇想介绍一些我对于 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 那么多的话，开发起来会比较快。