1. 为什么在做接口压测时我会首选Locust1.1 从一次压测焦虑说起Locust到底能解决什么问题如果你接手过任何一个“上线前必须证明自己能扛住”的项目就一定体验过那种半夜盯着压测报告不敢睡的焦虑。用其他工具压出来的曲线明明很漂亮一到线上就被用户打爆的情况我遇到不止一次。后来复盘才发现问题往往出在压测脚本和真实用户行为差得太远——所有人都在用同一个步调刷新同一个接口这跟真实流量完全不是一回事。Locust 解决的核心问题就是把“模拟用户”这件事做得足够真实。它不是一个录制回放工具也不是一个写死并发数的发压器。你可以用 Python 代码定义用户行为什么时候登录、什么时候翻页、思考多少秒、失败后怎么处理。这些逻辑几乎不受工具限制想怎么模拟就怎么模拟。这个特性让它特别适合两类场景。一类是接口级性能验证比如压测电商下单链路、支付回调、消息推送等核心接口需要精确控制请求频率和业务参数另一类是端到端全链路压测比如模拟大量用户同时打开 App、浏览商品、加购、结算的完整流程这时用代码写行为比用录制脚本维护起来靠谱得多。很多人问过我 Locust 和 JMeter 怎么选。我的习惯是如果团队里写代码的人多、接口逻辑复杂、需要灵活控制请求体选 Locust如果团队以测试工程师为主、依赖现成插件和录制功能、需要和 CI 深度集成且不想写代码选 JMeter 更顺手。工具没有绝对优劣关键是场景匹配。1.2 对比 JMeter 等工具Locust 的核心优势在哪里为了说清楚 Locust 的优势我整理了一份自己在选型时反复看的对比表列的是最影响实际使用体验的几个维度而不是官网上那些花哨的功能清单。对比维度LocustJMeter脚本形式Python代码灵活度极高XML/可视化树维护复杂脚本时比较痛苦用户行为模拟可通过 wait_time、task 组合精确模拟思考时间和行为比例需要搭配随机定时器插件配置繁琐结果监控Web UI实时图表数据可导出默认监听器图表聚合报告需额外配置扩展能力继承 User 类就能自定义协议比如 WebSocket、gRPC扩展需编写 Java 插件门槛较高分布式压测内置 master/worker 模式一条命令搞定分布式配置较复杂需要额外处理 CSV 数据共享单看表格可能体会不深我说一个实际例子。之前做移动端网关压测业务方要求模拟“凌晨大促”场景用户行为是先有 30% 的人疯狂刷新首页10 秒后有 60% 的人涌入商品详情页再往后又有 20% 的人反复提交订单。这种带有时间窗口和比例切换的行为在 JMeter 里需要靠多个线程组加定时器加控制器才能拼出来而在 Locust 里就是一个普通的 Python 循环加 time.sleep配合 task 权重就能完成。维护成本和试错成本完全不在一个量级。Locust 第二个让我离不开的优势是它天生就和 Python 生态打通。压测数据可以直接用 pandas 二次处理请求签名可以直接调用项目里的加密工具库甚至可以从数据库里实时读取压测账号。这些操作在 JMeter 里往往要靠 BeanShell 或 JSR223 脚本硬写写起来别扭排错也更麻烦。2. 环境准备与最小可用脚本2.1 安装与版本选择一套干净的 Python 环境Locust 的安装没什么坑前提是你别和系统自带的 Python 环境硬刚。我强烈建议在虚拟环境里安装避免污染全局环境也避免和公司内部其他 Python 项目打架。python -m venv locust_env source locust_env/bin/activate # Windows 下是 locust_env\Scripts\activate pip install locust安装完成后可以验证一下版本locust --version当前主流版本是 2.xAPI 和 1.x 相比有不小的变化网上很多老教程用的是from locust import HttpLocust这个类在 2.x 里已经改成了HttpUser。如果你照着老教程写代码跑报错大概率是版本语法问题。我的建议是直接用 2.x别犹豫。这里顺带说一个经验如果你的压测机是 Windows安装完如果发现敲locust命令没反应多半是 Python Scripts 目录没进 PATH重新配置一下环境变量即可。macOS 用户如果遇到 openssl 相关的报错通常是 Python 版本太老用 Python 3.8 以上会省心很多。2.2 写一个最简压测脚本先让工具跑起来很多人一开始就被“怎么写压测脚本”吓住了其实 Locust 脚本本质上就是一个普通的 Python 文件。它定义了用户类用户类里声明要执行的任务然后让这些任务循环运行。创建一个locustfile.py内容如下from locust import HttpUser, task, between class WebsiteUser(HttpUser): wait_time between(1, 3) task def load_index(self): self.client.get(/)这就是一个完整的、能跑的压测脚本。它做的事情很简单每次请求首页之前随机等待 1 到 3 秒然后用 GET 请求访问根路径。我解释一下几个关键点的作用因为很多人虽然能跑通但完全不知道自己在写什么HttpUser表示一个继承了 HTTP 能力的模拟用户。它内部会自动帮你管理一个 HTTP 会话这意味着 cookies、session 会被自动保存适合模拟登录后的连续操作。task给下面的函数打上标记表示这是一个用户会执行的任务。Locust 会随机挑选任务来执行不会固定死顺序。between(1, 3)任务与任务之间的等待时间单位是秒。这个时间差用来模拟真实用户的“思考时间”谁也不会盯着页面每秒都点一次。运行脚本的方式很简单在命令行执行locust -f locustfile.py --hosthttps://example.com默认会启动 Web UI浏览器打开http://localhost:8089填入并发用户数和 spawn rate就能开始压测。但这里我要特别提醒一句最简脚本只是让你跑通流程千万不要拿它直接压测真实业务。因为真实用户的请求不会永远只打一个 URL也不会永远用同一个步调最简脚本跑出来的结果只能说明工具能工作不能说明系统能抗住。3. 核心用法拆解Locust 脚本的关键 API3.1 HttpUser 与 task 装饰器的工作机制要真正用好转 Locust必须先理解它的事件驱动模型。每个模拟用户在 Locust 里是一个 greenlet协程它们被安排在同一个进程里并发运行。跟传统线程池相比这种模型的优势是单机可以起数千甚至上万用户而不需要开几千个线程去抢占资源。HttpUser类内部提供了client属性它本质上是requests.Session的一个封装。所以你在self.client上能用的方法比如get、post、put、delete参数跟 requests 库基本一致。这意味着你可以直接用headers、json、data传参完全不需要额外学习一套 DSL。task 装饰器有两种用法很多人只见过第一种task def visit_home(self): self.client.get(/) task(3) def visit_news(self): self.client.get(/news)第一种写法不带权重每个任务被执行的概率是相等的第二种写法带权重括号里的数字越大被选中的概率越高。比如上面这段代码visit_news被执行的频率是visit_home的三倍。这个权重机制非常实用因为它能很好地模拟真实流量分布——首页访问量大、低频接口访问量小。还有一种实测很有用的技巧是在一个用户类里用task组合多个步骤模拟一条完整业务链from locust import HttpUser, task, between class StoreUser(HttpUser): wait_time between(2, 5) def on_start(self): # 每个用户开始前先登录拿到 token resp self.client.post(/login, json{username: test, password: 123456}) token resp.json()[token] self.client.headers.update({Authorization: fBearer {token}}) task(5) def browse_products(self): self.client.get(/api/products) task(2) def add_to_cart(self): self.client.post(/api/cart, json{product_id: 1, count: 1}) task(1) def checkout(self): self.client.post(/api/order, json{cart_id: 1})这段脚本里我用了on_start方法它在每个模拟用户启动时执行一次相当于初始化用户环境。登录拿 token、设置 headers 这类一次性操作放在这里最合适。而任务本身则会被 Locust 按权重随机循环执行形成一个不断变化的用户行为流。3.2 wait_time 参数与模拟真实用户节奏wait_time是 Locust 脚本里最容易被忽视但又最能影响压测真实度的参数。说白了它就是用户做完一件事之后到做下一件事之间的停顿时间。Locust 提供了三种常用的时间策略我分别说下适用场景from locust import HttpUser, task, between, constant, constant_pacing class WaitUser(HttpUser): # 策略1完全固定等待 2 秒 # wait_time constant(2) # 策略2在 1 到 3 秒之间随机等待最常用 # wait_time between(1, 3) # 策略3固定每分钟执行 N 个任务适合匀速压测 wait_time constant_pacing(10) task def my_task(self): self.client.get(/)我重点讲一下constant_pacing很多人不太理解它的作用和 mathematically 含义。constant_pacing(10)的含义是无论任务本身执行了多长时间每个任务的开始时间间隔必须保持在 10 秒。比如任务本身耗时 7 秒那么任务结束后只等 3 秒就开始下一个如果任务本身耗时 12 秒那么下一个任务会立即开始通过不等待来把节奏拉回 10 秒的间隔。这种策略非常适合需要精确控制请求频率的场景比如限流测试或容量规划。我在实际压测中通常不会只用一种 wait_time而是根据业务特征组合使用。比如登录接口用户不会频繁点击等待时间可以设长一些而下拉刷新、翻页这类操作等待时间要短且抖动大用between(0.5, 2)更合理。我自己最常用的方式是创建多个用户类分别设置不同的 wait_time 和任务权重然后在启动压测时按比例模拟。这比把所有任务塞到一个类里更贴近真实流量也更容易定位是哪一类用户拖垮了系统。3.3 自定义用户压测非 HTTP 协议的扩展入口很多项目压测的不只是 REST 接口还有 WebSocket 长连接、gRPC 服务、TCP 自定义协议等。Locust 的好处是这些东西它都能支持只是你需要继承不同的基类。如果你想压测 WebSocket不引入额外库的话可以这样写一个最小用例import websocket from locust import User, task, between class WebSocketUser(User): wait_time between(1, 3) task def connect_and_send(self): ws websocket.create_connection(wss://example.com/ws) ws.send(ping) ws.recv() ws.close()这段代码用了基础的User类不再有client属性你需要自己控制连接和请求。当然更专业的做法是使用 locust-plugins 等扩展库它提供了WebSocketUser、KafkaUser等现成封装能帮你省掉大量重复代码。关于非 HTTP 协议的压测我给一个忠告这类压测的瓶颈往往不在工具本身而在连接复用和数据隔离。如果每个任务都新建连接大量时间会花在 TCP 握手阶段压测结果反映的不是业务处理能力而是连接建立能力。正确做法是在on_start里建立连接在任务里复用然后在on_stop里关闭连接减少连接开销带来的误差。4. 运行与监控启动压测的正确姿势4.1 Web UI 模式下如何设置并发与压实Locust 启动后默认打开 Web UI这应该是大多数人入门的起点。当你填入两个关键数字并开始压测时有没有想过它们到底代表什么Number of users总用户数整个压测过程最终会维持的并发用户总量。Spawn rate每秒启动用户数每个单位时间新增多少个用户。这两个参数配合起来决定了压测是“瞬间打满”还是“逐步加压”。举个例子如果你设置总用户数 1000每分钟启动 100 个那么需要 10 分钟才能让全部用户进入压测状态。这样做的好处是通过逐渐加压你能观察到系统在哪个并发量级开始出现响应变慢、错误率上升从而找到性能拐点。我个人的习惯分几个阶段加压而不是一上来就打满先跑 5 分钟预热用 50% 的目标并发。确认基础监控指标正常后再线性增加到 100%。保持满负荷运行 15 到 30 分钟观察是否有内存泄漏。这个观察非常重要很多系统能扛过短时间打满却会在持续运行中慢慢被拖垮。Web UI 上我主要看四个指标指标关注原因RPS每秒请求数直接反映系统处理能力如果 RPS 不再随用户数增长而增长说明容量已饱和响应时间Average/Median/95%中位数和 95 分位比平均值更能反映用户体感平均值容易被极端值拉偏失败率任何非 2xx 的响应都会被记为失败失败率超过 0.1% 就要停下来查问题活动用户数确认当前并发用户是否和设定值一致有时脚本报错会导致用户提前退出4.2 命令行模式和无界面压测技巧Web UI 虽然方便但真正跑通一个稳定的压测流程我几乎都靠命令行模式。尤其是在 CI 流水线里跑回归压测必须用命令行加非交互模式否则压根没法自动化。Locust 命令行的核心参数就那几个我列一下最常用的locust -f locustfile.py \ --hosthttps://api.example.com \ --headless \ -u 500 \ -r 50 \ -t 10m \ --csvresult \ --logfilelocust.log参数解释--headless无界面模式压测完自动退出。-u总用户数。-r每秒启动用户数。-t压测持续时间上面这个例子是 10 分钟也可以用30s、1h30m这种格式。--csvresult每 30 秒在指定路径下面写一份 CSV 结果文件方便后续处理。--logfile保存运行日志排查问题必备。命令行模式跑完以后你会得到多个 CSV 文件它们分别是_stats.csv最终统计数据、_stats_history.csv历史采样、_failures.csv失败详情、_exceptions.csv异常详情。我一般直接用 pandas 读_stats_history.csv做响应时间趋势图比 Web UI 上的图表更灵活。还有一个很有用的技巧如果你只想快速验证脚本有没有问题不真正压测加一个--run-time 10s --headless先跑 10 秒看是否有报错。别把一个问题多多的脚本直接压线上环境。4.3 分布式压测单机撑不住时怎么加机器单机跑 Locust 能模拟多少用户这取决于脚本复杂度和网络带宽。我之前遇到过一台 8 核 16G 的机器跑到 3000 用户时Locust 自身 CPU 已经接近 100%瓶颈完全在压测机而不在目标系统。这时候就需要分布式压测。Locust 的分布式模型分 master 和 worker。master 负责控制和汇总结果worker 负责实际执行任务。启动命令如下# 先启动 master locust -f locustfile.py --master --expect-workers4 # 再在 4 台机器上分别启动 worker locust -f locustfile.py --worker --master-host192.168.1.100几个注意点master 和 worker 必须共用同一个locustfile.py代码版本要一致否则行为会不一致。--expect-workers参数让 master 知道等多少个 worker 就绪方便自动化流程判断。worker 机器和 master 之间只需要局域网互通不需要暴露公网。分布式模式下的总 RPS 等于所有 worker 的 RPS 之和但数据汇总有延迟所以监控指标会有一点滞后这在超大规模压测时要注意不要据此做秒级告警。5. 常见问题与排查技巧实录5.1 运行时的高频报错和解决方法压测过程中遇到报错太正常了我把这几年被问得最多、自己也反复踩过的问题整理成一张速查表。问题现象可能原因解决方案ConnectionError: Max retries exceeded目标服务连接池被耗尽或网络超时检查目标系统监控看是否出现大量 TIME_WAIT适当调大 requests 的 timeoutTypeError: __init__() got an unexpected keyword argument你参考的是 1.x 老 API把HttpLocust换成HttpUsermin_wait/max_wait换成wait_time请求全部失败失败率 100%host 地址配置错误或接口需要鉴权先单独用 curl 验证接口连通性检查on_start里鉴权逻辑响应时间整体偏高但系统负载很低压测机自身性能瓶颈拆分 worker降低单机用户数压测机禁用代理环境变量数据量太大CSV 文件异常膨胀压测时间过长且采样频率高根据需要调整统计周期或用--csv-full-history控制采样上面这些坑里最让我印象深刻的是“压测机自身性能瓶颈”。有一次我压测一个本地微服务发现服务端 CPU 不到 20%但 RPS 就是上不去响应时间一直涨。捣鼓了半天才发现是压测机上没关公司代理所有请求都被代理转发了一遍白白浪费了大量带宽和连接资源。所以压测前一定要先检查环境变量里的HTTP_PROXY和HTTPS_PROXY最好在启动命令前显式清掉。5.2 提高压测真实度的进阶技巧把 Locust 脚本跑起来只是一个开始真正决定压测价值的是脚本和真实业务的重合度。这里分享几个我实战中一直用的进阶技巧。第一尽量不要直接压真实生产数据而是在测试环境里准备一套独立的压测数据。数据量不用特别大但要保证不同的用户访问不同的数据避免所有请求都打在同一个热点数据上导致结果失真。你可以在on_start里根据用户 ID 动态构造请求参数让每个模拟用户访问的资源独立。第二善用self.client.request方法它能在同一个请求里动态传入 headers、data 等参数。遇到一些签名认证逻辑比较复杂的接口你可以把签名计算封装成独立函数在任务里调用模拟出真实的业务请求。这比在脚本里硬编码 token 真实得多。第三使用HttpUser的client.trust_env False限制 locust 检测环境变量中的代理设置。很多代理变量在 CI 环境里自动注入如果不在代码层面强制关闭压测请求就可能被代理拦截导致响应时间虚高。from locust import HttpUser, task, between class SafeUser(HttpUser): wait_time between(1, 3) def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.client.trust_env False task def get_user(self): self.client.get(/api/users/1)第四通过events.test_start和events.test_stop钩子做一些压测前后的环境准备和清理。比如压测前标记测试数据压测结束后汇总结果并清理脏数据。这个技巧在自动化压测流程里非常实用可以完全不用手动干预数据库。5.3 从压测结果中判断瓶颈方向很多人盯着 Locust 的图表不知道到底该看什么。我的经验是分段式分析先看整体 RPS 曲线是否平整再看失败率有没有突然出现拐点最后看响应时间的 95 分位有没有持续上扬。如果 RPS 曲线在达到某个用户数后不再上升但响应时间还在涨说明系统已经进入容量饱和区此时要观察目标服务器的 CPU、内存、磁盘、网络指标判断瓶颈是 CPU 密集型还是 IO 密集型。加一个小建议压测时务必同步记录目标服务器的系统监控而不仅仅是 Locust 自己的输出。因为 Locust 只告诉你“系统响应变慢了”但“为什么变慢”需要去服务端找答案。我通常会在压测同一时间部署一个轻量监控脚本记录 CPU、内存、句柄数、TCP 连接数等指标配合 Locust 的统计结果一起看整体判断会准确得多。写在最后我做性能测试这几年的一个深刻体会是工具只是放大镜脚本才是探测仪。Locust 最大的价值不是它本身有多厉害而是它把“像真实用户一样思考”这件事的门槛降到了普通 Python 工程师也能轻松到达的水平。每次压测前我都会先问自己我的脚本真的模拟了用户的行为习惯吗如果答案是否定的那出来的曲线再漂亮也没有参考意义。最后再分享一个小技巧如果你刚开始接触 Locust从最简单的 GET 请求脚本写起先跑通一遍 Web UI再逐渐加入登录态、思考时间、多任务权重最后再碰分布式。这条路我走了一遍现在带新人也走这条路目前看是最少踩坑的路径。