从单机到集群：基于Locust的分布式性能测试实战与调优指南

1. 项目概述：从单兵作战到集群冲锋的性能测试实战

最近在帮一个电商项目做性能摸底，后端团队信誓旦旦说新架构能扛住双十一级别的流量，但光说没用，得拿数据说话。我第一时间想到的不是老牌的JMeter，而是Locust。为什么？因为它写测试脚本用的是Python，这对我们团队来说几乎没有学习成本，而且它那个Web UI实时看着“蝗虫”们（虚拟用户）冲锋陷阵的感觉，非常直观。但单机性能总有瓶颈，要模拟真正的海量用户，分布式压测是绕不开的坎。今天我就结合这个电商项目的实战，把Locust从入门到搭建分布式压测集群的全过程，包括那些踩过的坑和调优技巧，一次性讲透。无论你是刚接触性能测试的新手，还是想寻找JMeter替代方案的老兵，这篇都能给你一套可直接复用的“作战方案”。

2. Locust核心机制与快速入门

2.1 为什么选择Locust？不仅仅是“用Python写脚本”

很多人选择Locust的第一个理由是“可以用Python写测试逻辑”，这没错，但它的优势远不止于此。与JMeter的线程模型不同，Locust基于协程（gevent），这意味着单个进程可以轻松模拟数千个并发用户，资源消耗极低。在你那台普通的开发笔记本上，用JMeter跑几百个线程可能就开始卡顿了，但Locust跑几千个用户CPU可能才占用不到50%。其架构是主从（Master-Worker）模式，天生为分布式而设计，扩展起来非常优雅。

更吸引人的是它的理念：测试脚本就是普通的Python代码。你想怎么模拟用户行为就怎么写，从简单的HTTP请求到复杂的业务流程（如登录-浏览商品-加入购物车-下单），甚至与数据库、Redis、消息队列交互，都畅通无阻。这给了性能测试极大的灵活性和真实性。

注意：Locust的强项在于协议层的灵活模拟和资源高效利用，但对于需要录制浏览器行为或极度复杂的UI操作链，可能不是最优选。它更适合API、微服务等后端接口的性能测试。

2.2 五分钟搭建你的第一个压测场景

让我们从一个最简单的HTTP接口压测开始。假设我们要测试一个用户查询接口GET /api/user/{id}。

首先，安装Locust。强烈建议使用虚拟环境。

pip install locust

接下来，创建一个名为locustfile.py的文件，这是Locust默认识别的测试脚本入口。

from locust import HttpUser, task, between class QuickstartUser(HttpUser): # 模拟用户在每个任务执行后，等待1到2.5秒 wait_time = between(1, 2.5) # 标记为一个任务。weight属性表示任务权重，权重越高，被执行的频率越高。 @task(3) def query_user(self): # 假设我们要查询ID为1到100之间的用户 user_id = self.client.get("/api/user/1") # 这里client.get()返回一个Response对象，我们可以断言或记录 if user_id.status_code != 200: self.user.environment.events.request_failure.fire( request_type="GET", name="query_user", response_time=user_id.elapsed.total_seconds() * 1000, # 转毫秒 exception=None, ) @task(1) def index_page(self): self.client.get("/")

代码很简单，我们定义了一个用户类QuickstartUser，它有两个任务：query_user（权重3）和index_page（权重1）。这意味着在长时间运行中，query_user被执行的次数大约是index_page的3倍。wait_time用于控制用户思考时间，让模拟更贴近真实。

启动Locust：

locust -f locustfile.py

打开浏览器，访问http://localhost:8089，你会看到Locust的Web界面。输入要模拟的总用户数（Number of users）、每秒启动用户数（Spawn rate）和被测系统主机地址（Host），点击“Start swarming”就开始压测了。界面上会实时显示RPS（每秒请求数）、响应时间、失败率等关键指标。

2.3 解读你的第一份性能报告：关键指标怎么看

压测跑起来后，Web界面和最终生成的报告是分析性能的关键。你需要重点关注以下几个指标：

1. RPS（Requests per Second）：每秒请求数。这是系统吞吐量的直接体现。在并发用户数逐步上升的过程中，观察RPS的变化曲线。理想情况下，它应随着并发数增加而线性增长，直到达到系统瓶颈后趋于平稳或下降。
2. 响应时间（Response Times）：通常我们关注平均响应时间、中位数（50%分位）和95%/99%分位响应时间。平均响应时间容易受极端值影响，因此95%或99%分位值更能反映大多数用户的体验。例如，95%响应时间为200ms，意味着95%的请求在200毫秒内返回。
3. 失败率（Fails）：任何非2xx/3xx的HTTP状态码或未捕获的异常都会被视为失败。在性能测试中，即使系统没有崩溃，但若错误率超过0.1%（根据业务要求），通常也认为系统不可用。
4. 用户数（Number of Users）：当前活跃的虚拟用户数。注意区分“总用户数”和“并发用户数”。Locust中每个用户是独立运行的协程，其并发度取决于你的代码和wait_time。

在测试结束后，你可以在Web界面下载HTML格式的报告，里面包含了详细的图表和数据表格，方便你存档和分析。

3. 构建贴近真实业务的复杂测试场景

3.1 模拟有状态用户：处理登录与Session

大部分业务不是无状态的。我们的电商案例中，用户必须先登录才能下单。Locust 的HttpUser类中的client属性是HttpSession的实例，它自动保持了Cookie，因此处理登录会话非常简单。

from locust import HttpUser, task, between class AuthenticatedUser(HttpUser): wait_time = between(2, 5) host = "https://api.your-mall.com" def on_start(self): """每个虚拟用户开始运行时，只执行一次。用于登录。""" login_response = self.client.post("/api/login", json={ "username": "test_user", "password": "test_pass" }) if login_response.status_code == 200: self.auth_token = login_response.json().get("token") # 后续请求可以携带token self.client.headers = {"Authorization": f"Bearer {self.auth_token}"} else: # 登录失败，可以标记该用户停止运行或记录错误 self.stop(force=True) @task(4) def view_product(self): # 浏览商品列表 with self.client.get("/api/products", catch_response=True) as response: if "product_list" not in response.text: response.failure("Product list not found") @task(2) def add_to_cart(self): # 随机选择一个商品加入购物车 product_id = random.randint(1, 100) self.client.post(f"/api/cart/add/{product_id}", json={"quantity": 1}) @task(1) def checkout(self): # 结算下单，这是一个更复杂的链式操作 self.client.post("/api/order/preview") order_resp = self.client.post("/api/order/create", json={"address_id": 1}) if order_resp.status_code != 201: order_resp.failure(f"Create order failed: {order_resp.text}")

on_start方法是每个虚拟用户生命周期的起点，非常适合放置登录等初始化操作。catch_response=True参数允许你对响应内容进行更灵活的断言，而不仅仅是依赖状态码。

3.2 参数化与数据驱动：让测试数据“活”起来

用固定的ID（如/api/user/1）反复压测，不仅不真实，还可能因为缓存导致测试结果失真。我们需要参数化测试数据。

方法一：从文件中读取数据。比如，我们有一个user_ids.csv文件，里面有一万个用户ID。

import csv from locust import HttpUser, task, between class DataDrivenUser(HttpUser): wait_time = between(1, 3) # 在类加载时读取所有数据 user_id_pool = [] with open('user_ids.csv', 'r') as f: reader = csv.reader(f) for row in reader: user_id_pool.append(row[0]) @task def query_random_user(self): if self.user_id_pool: user_id = random.choice(self.user_id_pool) self.client.get(f"/api/user/{user_id}", name="/api/user/[id]")

这里用了name参数，它将所有不同ID的请求在统计时归并为“/api/user/[id]”，否则报告中会出现成千上万个不同的请求条目，无法分析。

方法二：使用队列（Queue）实现数据唯一性消耗。模拟注册、下单等需要唯一数据的场景时，确保每个虚拟用户取到的数据不重复。

import queue from locust import HttpUser, task, between # 全局数据队列 product_sku_queue = queue.Queue() # 初始化队列，放入1000个SKU for sku in [f"SKU_{i:06d}" for i in range(1000)]: product_sku_queue.put(sku) class UniqueOrderUser(HttpUser): wait_time = between(5, 10) @task def create_unique_order(self): try: sku = product_sku_queue.get_nowait() # 非阻塞获取，队列空则触发异常 except queue.Empty: # 数据用完，停止此用户 self.stop(force=True) return # 使用这个唯一的SKU创建订单 payload = {"sku": sku, "quantity": 1} self.client.post("/api/order", json=payload) # 通常测试中，我们不会把数据放回队列。这模拟了库存减少的场景。

3.3 控制测试节奏与自定义指标

Locust 默认的任务执行逻辑是随机权重选择。但有时我们需要更精确的控制，例如模拟“秒杀”场景：前58秒浏览，最后2秒集中下单。

from locust import HttpUser, task, between, events import time import gevent class SpikeTestUser(HttpUser): wait_time = between(0.1, 0.5) # 秒杀期间用户操作非常频繁 @task def spike_scenario(self): # 模拟前58秒的浏览行为 browse_start = time.time() while time.time() - browse_start < 58: self.client.get("/api/product/hot") gevent.sleep(random.uniform(0.5, 2)) # 用gevent.sleep代替time.sleep # 最后2秒，集中发起抢购请求 self.client.post("/api/seckill/submit", json={"product_id": 999})

此外，Locust 的自定义事件钩子非常强大，可以记录任何你关心的指标。例如，我想统计从“加入购物车”到“下单成功”这个业务链路的耗时：

from locust import events @events.request.add_listener def custom_request_handler(request_type, name, response_time, response_length, exception, context, **kwargs): """监听所有请求，可以在这里将数据发送到时序数据库如InfluxDB，用于更精细的监控""" if name == "/api/order/create" and not exception: print(f"订单创建成功，耗时: {response_time}ms") # 或者，在用户类中自定义一个指标记录 class MyUser(HttpUser): @task def business_flow(self): start_time = time.time() # ... 执行一系列请求 ... end_time = time.time() total_duration = (end_time - start_time) * 1000 # 毫秒 # 触发一个自定义事件来记录这个业务流耗时 self.environment.events.request.fire( request_type="BUSINESS", name="CompleteOrderFlow", response_time=total_duration, response_length=0, )

4. 突破单机瓶颈：搭建Locust分布式压测集群

当单台压力机无法产生足够压力，或者为了从不同网络区域发起请求时，就需要分布式压测。

4.1 分布式架构解析：Master与Worker的角色

Locust 分布式采用一个 Master 节点和多个 Worker 节点的模式。

• Master 节点：负责协调测试。它启动Web UI，收集所有Worker节点的统计数据并汇总展示，分发测试脚本和参数。Master本身不模拟任何用户。
• Worker 节点：负责干活。它们接收来自Master的指令，启动虚拟用户，执行测试脚本，向Master发送实时统计数据。你可以添加任意多个Worker来增加总并发用户数。

它们之间通过TCP协议通信。因此，网络需要允许Master和Worker节点间的指定端口（默认为5557和5558）互通。

4.2 一步步搭建分布式环境

环境准备：准备多台机器（或虚拟机/容器），所有机器都需要安装相同版本的Locust和Python依赖。将你的locustfile.py和测试数据文件同步到所有机器相同路径下。

步骤一：启动Master节点。 在一台机器上，使用--master参数启动Master。--expect-workers参数可以指定期望连接的Worker数量，达到后自动开始测试（可选）。

locust -f /path/to/locustfile.py --master --expect-workers 4 --host=https://your-target.com

启动后，Master会输出日志，等待Worker连接。

步骤二：启动Worker节点。 在每一台Worker机器上，使用--worker和--master-host参数启动，指向Master节点的IP地址。

locust -f /path/to/locustfile.py --worker --master-host=192.168.1.100

如果Master和Worker在同一台机器，--master-host可以是localhost或127.0.0.1。

步骤三：在Web UI中控制测试。 此时，打开Master节点的Web UI（http://master-ip:8089），你会看到界面和单机时一样。启动测试后，Master会将任务分发给所有已连接的Worker。在“Workers”标签页下，你可以看到所有在线的Worker节点及其状态。

4.3 分布式部署的实战技巧与避坑指南

1. 数据一致性与同步：确保所有Worker节点上的测试数据（如CSV文件）是一致的。如果使用队列消耗唯一数据，由于队列存在于各自进程的内存中，会导致数据重复消耗。解决方案：要么使用中央数据服务（如Redis队列），要么在Master上提前分区分配好数据范围给每个Worker。
2. 网络与防火墙：确保Master的5557和5558端口对所有Worker开放。在云环境或容器中，特别注意安全组和网络策略的设置。
3. 资源监控：压测时，不仅要监控被测系统，也要监控Master和Worker节点本身的资源（CPU、内存、网络IO）。Worker如果成为瓶颈，测试结果就不准确。可以使用htop,nload等工具。
4. 启动顺序：先启动Master，再启动Worker。Worker启动后会主动连接Master。如果Worker连接失败，检查网络和防火墙。
5. 动态增减Worker：Locust支持在测试运行期间动态添加新的Worker。新Worker加入后会自动同步测试状态并开始工作。这对于弹性扩容压测资源非常有用。
6. 使用Docker Compose一键部署：对于经常需要搭建分布式压测的环境，使用Docker是最佳实践。下面是一个简单的docker-compose.yml示例：

version: '3' services: master: image: locustio/locust ports: - "8089:8089" - "5557:5557" - "5558:5558" volumes: - ./locust-scripts:/mnt/locust command: -f /mnt/locust/locustfile.py --master -H https://your-target.com worker: image: locustio/locust depends_on: - master volumes: - ./locust-scripts:/mnt/locust command: -f /mnt/locust/locustfile.py --worker --master-host=master # 可以通过scale命令启动多个worker实例 # docker-compose up --scale worker=4

通过docker-compose up --scale worker=4就可以快速启动一个Master和四个Worker的集群。

5. 高级调优与结果深度分析

5.1 Locust性能调优：让你的压力机发挥全力

即使使用分布式，单个Worker的性能上限也需要优化。以下几点能显著提升单个Worker的压测能力：

• 关闭请求日志：默认情况下，Locust会记录每个请求的日志，这在高压下是巨大的I/O开销。在启动命令中添加--loglevel WARNING或--skip-log-setup来减少日志输出。

  locust -f locustfile.py --worker --master-host=master --loglevel WARNING

• 调整协程池大小：Locust 基于 gevent。虽然 gevent 能处理大量协程，但遇到阻塞型IO（如某些同步的HTTP客户端、文件读写）会拖累整个进程。确保你的测试代码和所有库都是异步友好的。对于无法避免的阻塞操作，可以使用gevent.threadpool将其放到线程池中执行。

• 优化测试脚本：

  • 避免在任务循环中创建大量临时对象，减少GC压力。
  • 使用连接池：对于HttpUser，Locust 内部使用了requests.Session，它本身具有连接保持和池化功能。但如果使用其他客户端（如自定义的gRPC客户端），务必自己实现连接池。
  • 精简断言逻辑：catch_response=True和复杂的响应内容解析会消耗CPU。在生产压测中，可以考虑只对关键业务字段做简单断言，或者将详细校验放到非压测阶段。

• 操作系统限制：Linux系统下，调整单个进程可打开的文件描述符数量上限（ulimit -n）。模拟大量并发连接时，很容易达到默认上限（通常是1024）。可以将其提高到65535或更高。

  ulimit -n 65535

5.2 结果分析与瓶颈定位：从数据到洞察

压测不是为了把系统打挂，而是为了发现瓶颈。当RPS上不去或响应时间飙升时，如何定位？

1. 观察曲线拐点：在Locust的“Charts”标签页，观察“Total Requests per Second”和“Response Times”曲线。随着用户数增加，RPS曲线何时从线性增长变为平缓甚至下降？那个点就是系统的当前性能拐点。同时，观察响应时间曲线是否在同一时刻开始急剧上升。

2. 分层定位法：

   • 压力机本身：通过监控工具（如top,vmstat）查看Worker节点的CPU、内存、网络带宽是否吃满。如果压力机先满了，那这个数据就是失真的，需要增加Worker或优化脚本。
   • 网络层：使用ping,traceroute或mtr检查网络延迟和丢包。使用netstat查看是否存在大量TIME_WAIT连接，这可能意味着需要调整被测系统的TCP/IP内核参数。
   • 被测系统：
     • 应用服务器：查看应用日志（错误、超时）、监控应用服务器的线程池、连接池使用情况。例如，Tomcat的maxThreads，数据库连接池的maxActive。
     • 数据库：这是最常见的瓶颈。监控数据库的CPU、IOPS、慢查询日志。压测时，数据库的活跃连接数是否暴增？是否存在死锁或全表扫描？
     • 缓存：检查Redis/Memcached的命中率。如果命中率骤降，可能导致大量请求穿透到数据库。
     • 外部依赖：调用第三方API或服务的响应时间是否变长？

3. 对比与趋势分析：不要只做一次压测。在代码发布前后、配置调整前后，用相同的测试场景和脚本进行压测，对比关键指标（如95%响应时间、最大RPS）。这能最直观地评估变更带来的性能影响。

5.3 常见问题排查实录（踩坑记录）

问题一：Worker节点显示“Missing”或频繁断开连接。

• 可能原因：网络不稳定，防火墙阻断，或者Master/Worker版本不一致。
• 排查：在Worker节点上使用telnet master-ip 5557测试端口连通性。检查Master和Worker的Locust版本号是否完全相同。

问题二：测试启动后，RPS始终为0或非常低。

• 可能原因：
  1. 测试脚本中的wait_time设置过长，导致用户大部分时间在“思考”。
  2. 任务（@task）定义得太少或权重配置不合理。
  3. 脚本中存在异常，导致用户任务提前结束。
• 排查：在Worker节点的日志中查找异常信息。在脚本中增加打印日志，确认任务是否正常执行。临时将wait_time设为constant(0)看看极限情况下的RPS。

问题三：响应时间出现个别极高的异常值（毛刺）。

• 可能原因：
  1. 被测系统有GC（垃圾回收）停顿，如Java应用的Full GC。
  2. 数据库偶尔出现慢查询。
  3. 网络抖动。
• 排查：查看被测系统的GC日志和数据库慢查询日志。在Locust中，关注99%分位和99.9%分位的响应时间，它们对毛刺更敏感。可以配合APM工具（如SkyWalking, Pinpoint）进行链路追踪，定位具体慢在哪一个环节。

问题四：分布式压测时，总用户数达不到预期。

• 可能原因：--expect-workers参数设置不正确，或者部分Worker节点资源已耗尽。
• 排查：在Master的Web UI“Workers”页确认实际连接的Worker数量。登录到各个Worker节点，使用top命令查看locust进程的CPU使用率。如果某个Worker的CPU持续100%，说明它已经达到性能上限，需要优化脚本或在该节点上启动多个Worker进程（使用不同的--worker端口）。