# 用 Locust 压测一个网站，记录一下学习过程

最近想给自己的一个小项目做个压力测试，看看能扛多少并发。之前一直听人提过 Locust，说是用 Python 写脚本就能压测，比 GUI 工具轻量，正好借这个机会学一下。

花了半天摸索下来，感觉这个工具确实挺顺手的，踩过几个坑，也有一些心得，干脆整理成一篇博客，一方面当自己的学习笔记，另一方面也给同样想入门的朋友一个参考。

## 为什么选 Locust

说实话，选 Locust 的理由很简单：**它用 Python 写测试脚本，我熟。**

性能测试工具其实挺多的，JMeter、k6、wrk 之类的我都听过，但要么是 GUI 点来点去不方便版本控制，要么是要学一门新的脚本语言。Locust 好处是脚本就是一个普通的 Python 文件，你平时怎么写 Python 就怎么写，条件判断、循环、读文件、调库，该怎么来怎么来。

对我这种不是专业做性能测试、只是偶尔想压一下自己服务的开发者来说，这种"门槛低、够用就好"的工具最合适。

## 这篇会写什么

就按我自己学的顺序来：

先用 `uv` 搭好环境、跑通第一个最简单的测试，看看 Locust 长什么样子；然后记录一下我在真实压测里用到的几个常见场景——登录、权重、参数化、自定义断言；再聊聊单机压测不够用的时候怎么搞分布式。

最后会列几个我自己踩过的坑，都是当时卡了好一会儿才绕出来的，提前说一下省得你也走弯路。

文章里的代码都是我自己跑通过的，可以直接复制运行。如果有写错的地方，欢迎在评论区指正——毕竟我自己也才学了没多久。

好，开始。

---

## 一、5 分钟跑通第一个测试

### 环境准备（用 uv）

我用 `uv` 来管 Python 环境。之前单独写过一篇 `uv` 的介绍（[链接](https://blog.csdn.net/qq_45913026/article/details/160227336?spm=1001.2014.3001.5501)），这里就不展开讲了，只给命令:

```bash
# 创建项目目录
mkdir locust-demo && cd locust-demo

# 初始化 uv 项目
uv init

# 添加 locust 依赖
uv add locust
```

三条命令搞定。`uv` 会自动处理虚拟环境、Python 版本（Locust 目前要求 Python 3.10+），你不需要手动 `python -m venv` 再 `source activate` 那一套。

如果你还是习惯 `pip`，等价命令是：

```bash
python -m venv .venv
source .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install locust
```

装完之后确认一下：

```bash
uv run locust -V
# 或者 pip 方式：locust -V
```

能打印出版本号就说明装好了。

### 三个核心概念

在写第一行代码之前，先看一下 Locust 的核心概念，用下面这张图就能理解：



![Locust 执行流程图](https://developer.qcloudimg.com/http-save/yehe-11760308/0eed40c911820940294c1fc38c67a3ed.png)




简单说就是：

- **HttpUser** 代表一个模拟用户。每个虚拟用户都是这个类的一个实例，Locust 会在后台用协程（greenlet）给你开一堆这样的实例出来，每个都独立跑自己的任务。
- **@task** 装饰的方法就是这个用户会执行的动作。Locust 会在这些 task 里随机挑一个执行，执行完等一会儿，再挑一个，循环往复。
- **wait_time** 是每次 task 执行完之后的等待时间。它模拟的是"真实用户不会连续不停地点击"，把它设成 0 虽然看起来压力更大，但其实不真实，后面会专门讲这个坑。
- **on_start** 是每个虚拟用户启动时执行一次的钩子，用来做登录这种一次性的初始化。
- **self.client** 是 Locust 自带的 HTTP 客户端，每个用户独立，接口跟 `requests` 库几乎一模一样。

### 第一个 locustfile.py

在项目目录下新建一个 `locustfile.py`：

```python
from locust import HttpUser, task, between

class QuickstartUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def get_homepage(self):
        self.client.get("/")

    @task
    def get_headers(self):
        self.client.get("/headers")
```

就这么几行，已经是一个可以跑的压测脚本了。

### 启动！

```bash
uv run locust -f locustfile.py
```

终端会打印一行：

```
[INFO] Starting web interface at http://0.0.0.0:8089
```

浏览器打开 `http://localhost:8089`，你会看到 Locust 的启动页面，让你填三个参数：

- **Number of users**：同时模拟的用户数，先填 50 试试
- **Ramp up**：每秒启动几个用户，填 5（意思是 10 秒内把 50 个用户全部拉起来）
- **Host**：要压测的目标地址，填 `https://httpbin.org`（这是一个公开的测试 API）

点 "Start"，压测就开始了。

几秒钟后，Statistics 页能看到每个接口的实时数据：请求数、失败数、中位响应时间、P95、RPS。切到 Charts 页能看到曲线图，Failures 页能看到报错详情。压够了就点 "Stop"。

第一个测试就跑完了。是不是比想象的简单？

这里有个地方值得停下来想一下：**我们没写任何"压测逻辑"，只是描述了一个用户会做什么动作，剩下的并发控制、统计、可视化 Locust 都帮你搞定了。** 这就是它所谓"测试即代码"的意思——你只管写业务，压测是框架的事。

当然，真实业务不会这么简单。下一节来看几个更实际的场景。

---

## 二、四个真实场景

### 场景 1：带登录态的接口

大部分业务接口都要登录才能访问。Locust 提供了 `on_start` 钩子，每个虚拟用户"启动"时会执行一次，非常适合放登录逻辑：

```python
from locust import HttpUser, task, between

class AuthenticatedUser(HttpUser):
    wait_time = between(1, 3)

    def on_start(self):
        # 每个虚拟用户启动时登录一次
        response = self.client.post("/login", json={
            "username": "testuser",
            "password": "testpass"
        })
        token = response.json()["access_token"]
        # 把 token 塞到后续请求的 header 里
        self.client.headers.update({
            "Authorization": f"Bearer {token}"
        })

    @task
    def get_profile(self):
        self.client.get("/api/profile")

    @task
    def get_orders(self):
        self.client.get("/api/orders")
```

关键点：`self.client` 是每个用户独立的，所以你在 `on_start` 里设置的 header，只会作用于这个用户后续的请求，不会污染其他用户。这个隔离性是 Locust 设计得挺贴心的一个地方。

如果你的 token 有过期时间，可以再加一个 `on_stop` 做登出，或者在 task 里检测到 401 之后重新登录——这种逻辑就是普通 Python 代码，你想怎么写都行。

### 场景 2：权重分配

真实用户的行为不是均匀的。一个电商网站，大部分人在浏览商品，少部分人会加购物车，只有很小一部分真的下单。如果你的压测脚本是 1:1:1 的比例去压，结果会严重偏离真实情况。

`@task` 装饰器可以传一个数字作为权重：

```python
class ShoppingUser(HttpUser):
    wait_time = between(2, 5)

    @task(10)   # 权重 10
    def browse_products(self):
        self.client.get("/products")

    @task(3)    # 权重 3
    def add_to_cart(self):
        self.client.post("/cart", json={"product_id": 1001})

    @task(1)    # 权重 1
    def checkout(self):
        self.client.post("/checkout")
```

权重是相对值，这里的比例就是 **10:3:1**，也就是浏览、加购、下单大概按 10:3:1 的概率触发。Locust 会按这个分布随机挑 task 执行。

设权重的时候建议你查一下自己服务的真实访问日志，照着线上的实际比例来设。很多人容易凭感觉拍脑袋设，但真实比例和感觉往往差好几倍——这种压测结果是误导性的，还不如不测。

### 场景 3：参数化，每个用户用不同数据

很多场景下，每个虚拟用户应该用不同的数据。比如压测一个登录接口，如果 100 个用户都用同一个账号登录，后端可能走了缓存，压出来的数据不准。

简单做法是用一个 CSV 文件存测试账号，然后在脚本里读：

```python
import csv
import random
from locust import HttpUser, task, between

# 在文件顶部加载一次，所有用户共享
with open("users.csv") as f:
    USER_CREDENTIALS = list(csv.DictReader(f))

class ParameterizedUser(HttpUser):
    wait_time = between(1, 3)

    def on_start(self):
        # 每个虚拟用户启动时随机挑一个账号
        creds = random.choice(USER_CREDENTIALS)
        self.client.post("/login", json=creds)

    @task
    def get_data(self):
        self.client.get("/api/data")
```

`users.csv` 大概长这样：

```csv
username,password
alice,pass123
bob,pass456
charlie,pass789
```

这里有个细节：CSV 文件的读取写在类外面，这样只会读一次，所有用户共享这份数据；如果你把它写到 `on_start` 里，每个用户都会去读一次文件，启动几千个用户的时候就会很慢。

如果你需要"每个用户用一个独立的账号，不重复"，可以用 `itertools.cycle` 或者一个带锁的迭代器，稍微复杂一点但也就是普通 Python 代码的事。

### 场景 4：自定义断言

默认情况下，Locust 只看 HTTP 状态码——200-399 算成功，400+ 算失败。但很多接口就算返回 200，业务层面也可能是失败的，比如：

```json
{"code": 500, "message": "余额不足"}
```

这种情况下，你需要自定义判断逻辑。`self.client` 提供了一个上下文管理器模式：

```python
from locust import HttpUser, task, between

class CustomAssertUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def place_order(self):
        with self.client.post(
            "/api/order",
            json={"product_id": 1001, "quantity": 2},
            catch_response=True
        ) as response:
            if response.status_code != 200:
                response.failure(f"HTTP {response.status_code}")
            elif response.json().get("code") != 0:
                response.failure(f"业务失败: {response.json().get('message')}")
            else:
                response.success()
```

关键是 `catch_response=True` 这个参数，它让你可以手动调 `response.success()` 或 `response.failure()`。写了自定义断言之后，Failures 页面能看到具体的业务错误原因，排查起来方便很多。

这四个场景基本能覆盖日常压测 80% 的需求。接下来聊一个进阶话题。

---

## 三、单机不够用怎么办：分布式压测

单台机器能压出多大 QPS？这个问题没有标准答案，取决于你的脚本复杂度、网络、CPU。但有几个信号可以判断单机到瓶颈了：

- Locust 自己的 CPU 占用接近 100%（你要压的是目标服务，不是把自己压死）
- 目标服务的响应时间突然暴涨，但实际 QPS 上不去
- 终端里开始出现 "CPU usage warning" 警告

到了这种程度，就该上分布式了。Locust 的分布式架构很简单：


![分布式架构测试图](https://developer.qcloudimg.com/http-save/yehe-11760308/e0450001ef811a7ee6cac1b4faf86bf8.png)



一个 **master** 负责调度和收集数据，多个 **worker** 负责真正发请求。

在一台机器上启动 master：

```bash
uv run locust -f locustfile.py --master
```

在另外几台机器（或者同一台的不同终端）启动 worker：

```bash
uv run locust -f locustfile.py --worker --master-host=<master-ip>
```

注意两点：

1. **所有 worker 必须有完全相同的 `locustfile.py`**，Locust 不会自动同步代码给 worker，你要自己用 `scp`、Git、或者 Docker 镜像把脚本分发过去。
2. **worker 数量建议等于 CPU 核心数**。Locust 基于 gevent，单进程吃不满多核，所以一台 8 核机器你可以起 8 个 worker。

启动好之后，master 的 Web UI 用起来跟单机一模一样，Locust 会自动把用户均匀分配给各个 worker。

什么时候需要分布式？我的经验是：**你要压的 QPS 超过 1000，或者你的脚本里有复杂的业务逻辑导致单机用户数撑不到几百，就可以考虑了。** 压几十上百 QPS 的场景，单机足够。

---

## 四、我踩过的几个坑

### 坑 1：用户数 ≠ QPS

刚开始我以为"1000 个虚拟用户"就等于"1000 QPS"，后来才反应过来，这俩完全不是一回事。

一个虚拟用户在 Locust 里的行为模式是：**执行 task → 等待 wait_time → 再执行 task**。如果 wait_time 是 `between(1, 3)`，平均 2 秒，那一个用户平均每 2 秒发一个请求，也就是 0.5 QPS。1000 个用户才是 500 QPS。

所以设用户数的时候要反推：**目标 QPS × 平均 wait_time = 需要的用户数**。想压 1000 QPS、wait_time 平均 2 秒，那就是 2000 个用户。

### 坑 2：wait_time 设成 0 不是"最大压力"，而是"不真实"

一开始我觉得 `wait_time = 0` 能压出最大压力，后来想明白这是个伪命题。

真实用户不会 0 间隔地连续点击。wait_time 设成 0，你得到的是一个"机器人式的极端场景"，反映不出正常业务下的服务表现。更糟的是，如果你的服务有连接池、限流、缓存预热这些机制，0 等待的压测会让这些机制的表现偏离实际线上情况。

我现在的做法是：**对着线上日志看用户的真实点击间隔，用 `between(min, max)` 设一个接近的范围**。如果实在没有数据，1-5 秒是个比较保守合理的默认值。

### 坑 3：只看平均值会被骗

Locust 的 Statistics 页默认显示的是平均响应时间。但平均值在性能测试里是一个**非常有误导性**的指标。

举个例子：100 个请求，99 个是 50ms，1 个是 5000ms，平均值是 99.5ms，看起来很好。但实际上 1% 的用户经历了 5 秒的卡顿，在生产环境这是个严重问题。

**养成看 P95 和 P99 的习惯。** P95 = 95% 的请求比这个时间快，P99 = 99% 的请求比这个时间快。这两个指标才真正反映"最差情况下的用户体验"。Locust 的 Statistics 页有这两列，但位置偏右，一开始容易忽略。

### 坑 4：压测机自己先挂了

我第一次做分布式压测的时候，开了几千个用户，结果 Locust 自己的 CPU 被打满，压出来的数据完全失真——不是目标服务扛不住，是压测机先扛不住了。

判断方法很简单：**压测时看一眼压测机自己的 CPU 和网络带宽**。如果 CPU 接近 100%，或者带宽跑满了，压测结果就不可信。解决方案要么是降低用户数、简化脚本，要么就是上分布式，多开几台 worker。

---

## 结尾

这篇就记到这里。Locust 的东西还有不少没覆盖的，比如和 Prometheus/Grafana 对接做实时监控、在 CI/CD 里跑性能回归、用自定义客户端压测 WebSocket 或 gRPC 之类的，以后如果用到再专门写。

总体感受：**Locust 是一个"门槛低、天花板不低"的工具**。简单场景五分钟上手，复杂需求靠普通 Python 代码也基本都能搞定。对不是专职做性能测试的开发者来说，够用，而且用着顺手。

如果你也想试试，我的建议是别一上来就读完整的官方文档，就从第一节那个 10 行的 `locustfile.py` 开始跑，跑通了再按自己业务的需要一点点往上加功能。这个工具的学习曲线基本是线性的，不会突然陡峭，不用太担心。

最后再啰嗦一句：压测的意义不在于"跑出一个漂亮的 QPS 数字"，而在于**提前发现你的服务在什么地方会先挂**。数字本身没那么重要，挂的方式才是你真正要了解的东西。

以上就是我学习 Locust 的心得。如果你发现文章里有错误，或者有更好的实践想分享，欢迎留言交流。

最近想给自己的一个小项目做个压力测试，看看能扛多少并发。之前一直听人提过 Locust，说是用 Python 写脚本就能压测，比 GUI 工具轻量，正好借这个机会学一下。

用 Locust 压测一个网站，记录一下学习过程

后端

测试

开发工具

学习Locust压测工具的使用心得，包括环境搭建、核心概念讲解、真实场景应用（登录态、权重分配、参数化、自定义断言）及分布式压测技巧。分享常见踩坑经验，帮助开发者快速上手这个轻量级Python压测工具，提升Web服务性能测试效率。

性能测试

压力测试

Windows

Python

2026年中大促 | AI 领航 智绘未来

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

用 Locust 压测一个网站，记录一下学习过程-腾讯云开发者社区-腾讯云

用 Locust 压测一个网站，记录一下学习过程

用 Locust 压测一个网站，记录一下学习过程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐