1. 项目概述为什么我们需要分布式压测做性能测试的朋友尤其是后端开发或者测试工程师应该都遇到过这样的场景你写好了一个接口本地用JMeter或者Postman跑一下响应速度嗖嗖的感觉良好。但一上线用户量稍微上来点服务器就开始报警CPU飙升响应超时甚至直接宕机。问题出在哪很多时候问题就出在测试环境和真实环境的压力根本不在一个量级上。单机发起的请求对于现代动辄需要承载数万、数十万并发用户的系统来说无异于隔靴搔痒。这就是我们今天要聊的分布式压力测试的核心价值。它不再是“一台机器模拟几百个用户”而是“多台机器协同模拟成千上万个真实用户的行为”从而在测试阶段就尽可能逼近甚至超越线上真实压力提前发现系统的性能瓶颈和临界点。而Locust正是实现这一目标的利器中的利器。它用Python编写测试脚本就是普通的Python代码对开发者极其友好它自带Web UI可以实时观察压测情况更重要的是它原生支持分布式运行架构简单清晰让你能轻松地将测试压力从“小打小闹”提升到“狂风暴雨”的级别。简单来说如果你还在为单机压测无法突破性能瓶颈而烦恼或者想找一个比JMeter写脚本更灵活、比一些商业压测工具更轻量的方案那么通过Locust搭建分布式压测集群就是你接下来必须要掌握的技能。这不仅仅是工具的使用更是一种贴近真实生产环境的性能验证思维。2. Locust分布式架构核心原理解析在动手搭建之前我们必须先吃透Locust分布式模式的工作原理。这能帮助你在后续遇到各种“诡异”问题时快速定位根因而不是盲目地重启进程、修改配置。Locust的分布式运行模式采用经典的Master-Worker主从架构。这个架构非常清晰Master主节点只有一个。它不负责模拟任何用户即不产生任何请求压力。它的核心职责是协调和收集。它启动一个Web UI服务器默认端口8089用于下发测试任务、启动/停止测试并实时收集所有Worker节点汇报上来的统计数据进行聚合后展示在Web界面上。Worker工作节点可以有多个理论上可以无限水平扩展。它们是真正的“压力产生器”。每个Worker节点会从Master节点获取测试任务即要执行的Locust脚本然后独立地运行脚本模拟虚拟用户User执行任务并发起HTTP或其他协议请求。每个Worker会定期将自己的测试数据如请求数、响应时间、失败数等发送回Master节点。它们之间如何通信Locust默认使用ZeroMQ或TCP Socket进行节点间通信。当你启动Master时它会开启两个端口一个用于Web UI如8089另一个用于与Worker通信默认是5557。Worker启动时需要指定Master节点的IP和这个通信端口从而建立连接。一个关键概念集中式与分布式。很多人会混淆。Locust的分布式指的是压力生成器Worker是分布式的它们可以分布在不同的物理机或虚拟机上共同产生压力。但测试协调和数据收集是集中式的由唯一的Master节点负责。这保证了我们有一个统一的控制面和数据视图。与之相对的像JMeter可能通过“远程启动”的方式其控制节点运行JMeter GUI的机器本身也可能参与发压架构上略有不同。Locust的这种明确分离让架构更清晰资源利用也更合理Master可以是一台配置很低的机器。为什么分布式能提高压力压力并发用户数、每秒请求数RPS受限于单台机器的资源CPU、内存、网络带宽、端口数。单机Locust在模拟大量用户时可能会因为Python的GIL全局解释器锁、网络连接数限制、或机器本身性能而达到瓶颈。分布式模式将模拟用户的任务分摊到多台Worker机器上每台机器只负责一部分用户从而轻松突破单机资源上限实现压力叠加。例如单机最多模拟5000用户那么4台Worker理论上就能模拟20000用户。3. 环境准备与Locust核心脚本编写工欲善其事必先利其器。分布式压测的第一步不是急着启动多台机器而是准备好一个清晰、可复用的测试脚本和环境。3.1 环境搭建与依赖安装首先确保你的机器上安装了Python建议3.7及以上版本。Locust的安装极其简单pip install locust这条命令会安装locust及其核心依赖。验证安装是否成功locust -V如果输出类似locust 2.20.0的版本信息说明安装成功。对于分布式压测所有节点Master和所有Worker都必须安装相同版本的Locust并且能够访问到相同的测试脚本。版本不一致是导致莫名错误的常见原因。3.2 编写一个可分布式的Locust测试脚本Locust的脚本本质就是一个Python文件。我们从一个经典的HTTP API压测脚本例子开始并深入讲解其中每个部分对分布式运行的影响。from locust import HttpUser, TaskSet, task, between import json class UserBehavior(TaskSet): 定义虚拟用户的行为任务集。 在分布式环境下每个Worker上的每个用户实例都会独立运行这些任务。 # 每个用户执行任务前会调用一次on_start常用于登录等初始化操作 def on_start(self): 模拟用户登录获取token。注意这个token是每个用户独立的。 login_payload {username: test_user, password: test_pass} # 使用self.client发起请求它会自动记录到Locust的统计中 with self.client.post(/api/login, jsonlogin_payload, catch_responseTrue) as response: if response.status_code 200: resp_json response.json() self.token resp_json.get(token) # 将token存储在用户实例中 response.success() else: response.failure(fLogin failed with status code: {response.status_code}) # 登录失败可以停止这个用户的执行可选 self.interrupt() # 用task装饰器定义一个任务权重值表示执行频率 task(3) # 权重为3意味着执行频率较高 def get_user_info(self): 任务1获取用户信息 headers {Authorization: fBearer {self.token}} if hasattr(self, token) else {} with self.client.get(/api/user/profile, headersheaders, name/api/user/profile [GET]) as response: # 对响应进行断言判断业务是否成功 if response.status_code 200 and response.json().get(code) 0: response.success() else: response.failure(fUnexpected response: {response.text}) task(1) # 权重为1执行频率较低 def create_item(self): 任务2创建一个新项目 headers {Authorization: fBearer {self.token}, Content-Type: application/json} item_data {name: fTestItem_{self.user.id}, value: 100} with self.client.post(/api/items, jsonitem_data, headersheaders, name/api/items [POST]) as response: if response.status_code 201: response.success() else: response.failure(fCreate failed: {response.status_code}) # 可以定义更多任务... class WebsiteUser(HttpUser): 定义虚拟用户类。每个模拟用户都是这个类的一个实例。 # 指向上面定义的任务集 tasks [UserBehavior] # 用户执行完一个任务后等待多长时间秒再执行下一个任务。 # between(1, 5) 表示等待1到5秒之间的一个随机时间。 # 这个设置对模拟真实用户思考时间、控制RPS至关重要。 wait_time between(1, 5) # 每个用户建立HTTP连接时的基础超时时间秒 connection_timeout 10.0 # 网络请求超时时间秒 network_timeout 10.0分布式运行的关键脚本注意事项状态隔离on_start中获取的self.token是每个User实例独立的。在分布式运行时每个Worker上的每个用户都会独立执行on_start。绝对不要在脚本顶层定义全局变量并在多个用户间共享状态这会导致数据竞争和难以预料的行为。用户行为应该是无状态或实例状态隔离的。任务权重与等待时间task(weight)和wait_time共同决定了压力模型。在分布式模式下所有Worker遵循同一套模型Master只是协调开始和停止并不干涉每个Worker内部的任务调度。确保你的wait_time设置合理between(1,5)能有效避免请求变成单纯的“循环轰炸”更贴近真实用户操作间隔。请求命名name参数在self.client.get/post中设置name参数非常重要。Locust的统计报表会按name聚合。如果你不设置name默认会使用完整的URL路径。但像/api/items/123和/api/items/456会被统计为两个不同的条目不利于分析。通过name/api/items [GET]可以将同一类请求归并使报告更清晰。主机地址host脚本里没有写死的host。这个地址需要在启动Locust时通过--host参数指定如--host https://api.your-service.com。在分布式场景下所有Worker必须使用相同的目标主机。通常由Master在启动时指定Worker会自动继承。4. 分布式压测集群搭建与实战演练现在我们进入实战环节。假设你有三台Linux服务器可以是物理机、虚拟机或云主机IP分别为master_node_ip(用作Master)worker1_ip(用作Worker 1)worker2_ip(用作Worker 2)我们的目标是在这三台机器上部署并运行分布式Locust压测。4.1 第一步准备与共享测试脚本首先将上一节编写好的Locust脚本例如保存为locustfile.py放到一个所有节点都能访问的位置。有几种常见做法版本控制仓库推荐将脚本放在Git仓库中。在所有节点上拉取同一分支的同一版本代码。这是最规范、易于协同的方式。共享网络存储如NFS、Samba共享目录将脚本放在共享目录下。手动同步如果机器不多可以用scp命令手动拷贝到各个节点相同路径下。我们假设采用第一种方式所有节点都已将脚本克隆到了/home/user/loadtest/locustfile.py。确保所有节点Python和Locust环境一致。在所有节点上执行pip install locust并确认版本。4.2 第二步启动Master节点在master_node_ip机器上切换到脚本目录执行以下命令cd /home/user/loadtest locust -f locustfile.py --master --hosthttps://api.your-target.com参数解析-f locustfile.py: 指定要运行的Locust脚本文件。--master: 以Master模式运行。这是最关键的一个参数。--hosthttps://api.your-target.com: 指定被压测系统的基地址。所有在脚本中使用的相对路径如/api/login都会拼接到这个host之后。默认行为启动后Master会开启两个服务Web UI服务监听0.0.0.0:8089。你可以通过浏览器访问http://master_node_ip:8089来打开控制界面。Worker通信服务监听0.0.0.0:5557。等待Worker节点来连接。注意如果你的Master节点有防火墙必须放行8089Web访问和5557Worker连接端口。云服务器还需要在安全组规则中配置。启动成功后终端会显示类似以下信息[2024-05-XX ...] INFO/locust.main: Starting web interface at http://0.0.0.0:8089 [2024-05-XX ...] INFO/locust.main: Starting Locust 2.20.0 [2024-05-XX ...] INFO/locust.runners: Waiting for workers to be ready, 0 of 0 connected此时Web界面可以访问但“SLAVES”部分显示为0因为还没有Worker连接。4.3 第三步启动Worker节点分别在worker1_ip和worker2_ip机器上切换到脚本目录执行Worker启动命令在worker1_ip上cd /home/user/loadtest locust -f locustfile.py --worker --master-hostmaster_node_ip在worker2_ip上cd /home/user/loadtest locust -f locustfile.py --worker --master-hostmaster_node_ip参数解析--worker: 以Worker模式运行。--master-hostmaster_node_ip: 指定Master节点的IP地址或主机名。这是Worker能找到Master并注册自己的关键。注意这里没有指定--host参数。Worker会自动从Master那里继承--host的设置。确保Worker节点网络能够访问--host指定的目标地址。启动成功后Worker终端会显示连接成功的信息[2024-05-XX ...] INFO/locust.main: Starting Locust 2.20.0 [2024-05-XX ...] INFO/locust.runners: Connecting to master at master_node_ip:5557 [2024-05-XX ...] INFO/locust.runners: Connected to master at master_node_ip:5557同时在Master节点的终端和Web界面中你会看到Worker已连接。Web界面“SLAVES”部分会显示已连接的Worker数量例如2个。4.4 第四步通过Web UI执行分布式压测打开浏览器访问http://master_node_ip:8089。在Locust的Web界面中你会看到Number of total users to simulate: 要模拟的总用户数。这是所有Worker节点共同模拟的用户总数。比如你输入10000Locust Master会协调两个Worker让它们共同承担这10000个用户的模拟工作通常会自动均衡分配。Spawn rate (users spawned/second): 每秒启动的用户数。控制用户压力爬升的速率。Host: 这里会显示你启动Master时设置的--host不可更改。SLAVES: 显示已连接的Worker数量应为2。填写总用户数如10000和孵化率如100然后点击“Start swarming”。观察与控制Statistics标签页查看实时聚合的RPS、响应时间、失败率等关键指标。这些数据是所有Worker汇总后的结果。Charts标签页查看用户数、RPS、响应时间随时间变化的曲线图。Workers标签页可以看到每个Worker节点的状态、CPU使用率如果Worker是Locust 2.11版本且运行在支持psutil的系统上、当前模拟的用户数。这是分布式特有的视图用于监控各个压力生成器的负载是否均衡。Failures/Exceptions标签页查看失败的请求和抛出的异常。可以随时点击“Stop”停止测试或者点击“New test”重置统计数据开始新一轮测试。一个核心技巧如何确定每个Worker能模拟多少用户这没有固定公式取决于Worker机器本身的性能CPU、内存、网络和你的测试脚本复杂度请求频率、响应处理逻辑。一个实用的方法是渐进式加压。先在一个Worker上单独测试逐步增加用户数观察该Worker的CPU和内存使用率。当资源使用率达到70%-80%时记录下此时的用户数这大致就是该单机的能力上限。然后在分布式模式下将总用户数设定为单机上限 * Worker数量并留有一定余量。例如单机上限是3000用户有2个Worker那么总用户数可以设置为5000-5500进行测试。5. 高级配置、问题排查与性能优化分布式压测搭建起来不难但要跑得稳、数据准就需要关注一些高级配置和常见坑点。5.1 关键启动参数详解除了基本的--master、--worker、--hostLocust提供了许多参数来精细控制压测行为在分布式环境下尤其重要。--web-host/--web-port: Master节点上指定Web UI绑定的IP和端口。如果你想只允许本地访问Web界面可以设置--web-host127.0.0.1。--master-bind-host/--master-bind-port: Master节点上指定与Worker通信的Socket绑定的IP和端口默认5557。如果默认端口冲突可以修改。--worker: 如前所述启动Worker模式。--master-host/--master-port: Worker节点上指定Master的地址和通信端口默认5557。如果Master修改了--master-bind-portWorker的--master-port必须与之对应。--expect-workers: 在Master启动时使用例如--expect-workers5。Master会等待指定数量的Worker全部连接成功后才允许在Web UI上启动测试。这对于确保所有压力机就位后再开始非常有用。--headless/-u/-r: 在无UI模式下运行。--headless表示不启动Web UI-u指定用户数-r指定孵化率。这在结合CI/CD进行自动化压测时常用。分布式模式下可以在Master启动命令中加入这些参数直接开始测试无需点击Web UI。locust -f locustfile.py --master --expect-workers2 --headless -u 10000 -r 100 --hosthttps://api.target.com --run-time 10m--run-time: 指定测试运行时长例如--run-time 1h30m。时间一到测试自动停止。在自动化场景中防止测试无限运行。--csv/--html: 以CSV或HTML格式输出测试结果报告。分布式测试的聚合结果也会输出到这些文件中便于后续分析。locust -f locustfile.py --master --host... --csvresult --htmlreport.html5.2 分布式压测常见问题与排查实录即使按照步骤操作你也可能会遇到一些问题。下面是我在实践中总结的“踩坑记录”问题1Worker连接不上Master提示Connection refused或超时。排查思路网络连通性在Worker节点上执行telnet master_node_ip 5557或nc -zv master_node_ip 5557检查端口是否能通。防火墙/安全组确认Master节点的防火墙如firewalld、ufw和云服务商安全组已放行5557端口。Master绑定地址检查Master是否绑定到了0.0.0.0。如果启动Master时使用了--master-bind-host127.0.0.1那么只有本机可以连接。分布式环境下必须绑定到0.0.0.0或特定网络IP。命令错误确认Worker启动命令中的--master-host参数值是否正确不能是localhost或127.0.0.1除非Worker和Master在同一台机器但这失去了分布式意义。问题2Web UI上显示Worker已连接但启动测试后“Users”数量不增长或远低于设定值。排查思路Worker日志查看Worker节点的终端输出或日志是否有大量错误信息例如连接目标服务器失败、脚本语法错误、导入模块失败等。一个常见的错误是脚本中引用了Worker机器上不存在的Python模块。目标服务承受能力可能目标服务在压力下迅速崩溃或拒绝连接导致虚拟用户无法成功启动。观察目标服务的监控和日志。wait_time设置过大如果脚本中wait_time between(10, 30)意味着每个用户执行一个任务后要等待10-30秒那么用户数增长自然会非常缓慢。调整wait_time或提高孵化率Spawn rate。Worker资源瓶颈通过top或htop命令查看Worker节点的CPU和内存使用率。如果已经接近100%说明单台Worker已经满载无法孵化更多用户。需要增加Worker节点数量。问题3测试数据如总RPS波动非常大或者明显低于预期。排查思路网络延迟与带宽Worker节点与被测服务之间的网络质量差或者Worker节点本身的网络带宽已被打满。使用ping、traceroute或iftop等工具检查网络状况。“慢启动”效应如果设置了wait_time并且总用户数很大孵化率相对较低那么系统需要很长时间才能达到峰值压力。计算一下10000用户孵化率100用户/秒需要100秒才能全部启动。在这100秒内压力是逐渐上升的。聚合延迟Master默认每3秒从Worker收集一次数据。在Web UI上看到的RPS是3秒内的平均值并且有短暂延迟。这是正常现象。对于瞬时波动可以关注更长周期的趋势。检查脚本逻辑确认脚本中没有不必要的time.sleep()或非常耗时的本地计算如循环加密这些操作会阻塞单个用户的任务执行严重影响该用户线程/协程的吞吐能力。问题4如何监控Worker节点本身的资源使用情况解决方案Locust自带的Worker列表在较新版本会显示CPU使用率。但更全面的监控建议结合系统级工具使用htop或nmon在Worker节点上实时查看CPU、内存、负载。使用dstat或sar查看详细的网络I/O、磁盘I/O历史数据。关键指标CPU使用率是否持续高于80%、内存使用量是否接近耗尽、网络吞吐量是否达到网卡上限、系统负载Load Average1分钟负载是否持续高于CPU核数太多。任何一个指标成为瓶颈都会限制该Worker的发压能力。5.3 性能优化与最佳实践要让分布式Locust压测发挥最大威力以下几点经验值得参考Worker节点配置尽可能一致不同的硬件配置会导致发压能力不同可能造成压力不均。尽量使用相同或配置相近的机器作为Worker。优化Locust脚本性能避免阻塞操作在任务方法中避免使用同步的、耗时的I/O操作如读写大文件、同步网络请求。如果必须调用外部命令或库考虑其是否阻塞。谨慎使用task装饰器内的循环一个task方法应该尽快结束。如果需要重复操作应该拆分成多个task利用Locust的调度机制而不是在一个任务里写for i in range(100)。连接复用HttpUser使用的client默认会保持HTTP连接Session。确保你的目标服务也支持HTTP Keep-Alive这能大幅减少TCP连接建立的开销。使用更高效的模式Locust默认使用基于gevent的协程。对于计算密集型或特定I/O密集型的脚本可以尝试切换到多进程模式通过--processes参数仅在类Unix系统有效让每个Worker启动多个进程充分利用多核CPU。但要注意多进程模式下用户状态在进程间不共享。结果分析与瓶颈定位关注分位数响应时间不要只看平均响应时间。Web UI上提供的50%中位数、95%、99%分位数响应时间更能反映用户体验。比如95%分位响应时间激增说明有少量请求非常慢可能是遇到了数据库锁、缓存击穿等问题。结合系统监控压测时一定要同时监控被测服务的各项指标应用服务器线程池、数据库连接数、CPU、内存、磁盘IO、网络流量等。当Locust报告响应时间变长、失败率升高时去对照服务监控往往能快速定位瓶颈所在是应用代码问题数据库慢查询还是缓存服务过载。安全与清理压测数据隔离确保压测使用的是独立的测试数据库或测试环境避免污染生产数据。脚本包含清理逻辑对于创建资源的接口如POST /api/items可以考虑在on_stop方法或使用Locust的events钩子在测试结束后执行一些清理操作如删除测试创建的数据但这需要目标API提供相应的删除接口。更常见的做法是让测试环境定期自动重置。