Locust中self.client.get()不走代理或超时失效，因其默认忽略http_proxy环境变量且不继承requests全局超时，需显式设timeout元组并禁用trust_env以手动控制代理。
locust脚本里为什么self.client.get()不走代理或超时失效？
Locust 默认使用 requests 库发起 HTTP 请求，但它的底层会绕过系统代理（比如 http_proxy 环境变量），也不继承全局 requests 的默认超时配置。这会导致你本地调试时能通、压测时大量 ConnectionError 或卡死。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 显式设置超时：
self.client.get("/api/v1/user", timeout=(3, 7))—— 元组格式为(connect_timeout, read_timeout)，避免单点阻塞拖垮整个用户实例 - 如需走代理（例如对接测试网关），改用
HttpUser的client初始化参数：class MyUser(HttpUser): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.client.trust_env = False # 关闭 requests 自动读取环境变量代理 # 再手动注入 session-level adapter（可选） - 注意：Locust 2.0+ 已弃用
TaskSet，统一用@task装饰器，别混用旧写法导致任务不触发
并发数设到1000，实际QPS却上不去，是哪里卡住了？
Locust 的 QPS 上不去，90% 不是服务端问题，而是客户端资源或配置瓶颈。Locust 进程本身是单线程事件循环（基于 gevent），但每个虚拟用户（HttpUser 实例）仍需分配 socket 和内存，且受操作系统文件描述符限制。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 检查 ulimit：
ulimit -n，压测机至少设为65535；否则在高并发下会报OSError: [Errno 24] Too many open files - 避免在
@task中做同步 I/O（如time.sleep()、print()、写本地文件）—— 会阻塞 gevent 协程调度 - 用
--processes N启动多进程模式（Locust 2.15+），例如：locust -f load_test.py --processes 4，让 CPU 核心真正并行起来 - 观察 Locust Web UI 的 “Users” 页面：如果 “Hatching” 长时间不变成 “Running”，说明用户启动慢，大概率是初始化逻辑太重（比如在
on_start里做了耗时鉴权）
如何把压测结果和后端日志对齐，快速定位慢接口？
单纯看 Locust 的平均响应时间没用，关键是要知道哪次请求慢、慢在哪一环（DNS？连接？TLS？后端处理？）。Locust 默认不记录原始请求/响应头或耗时分段，得自己补。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 启用详细日志：启动时加
--loglevel DEBUG，然后在on_start中给self.client注入钩子：from locust import events @events.request.add_listener def on_request_success(request_type, name, response_time, response_length, exception, context, **kwargs): if exception and "timeout" in str(exception).lower(): print(f"[TIMEOUT] {name} @ {response_time}ms") - 给关键请求加唯一 trace ID：
headers={"X-Request-ID": str(uuid.uuid4())}，再配合后端日志（如 Nginx access_log 或应用日志）grep 定位完整链路 - 不要只信 Locust 报的 “95% percentile”，导出 CSV 后用 pandas 分组统计：
df.groupby("Name")["Response Time"].quantile(0.99)，常发现某个路径拖垮整体 P99
压测中出现大量 ConnectionRefusedError 或 MaxRetryError 怎么办？
这类错误不是网络不通，而是目标服务已拒绝新连接 —— 很可能是后端连接池打满、反向代理（如 Nginx）的 worker_connections 不足，或数据库连接数上限被突破。Locust 自身不会伪造“连接被拒”，它只是如实反映下游状态。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 先确认后端是否真扛不住：用
ss -s或netstat -an | grep :80 | wc -l看 ESTABLISHED 连接数，对比服务端最大连接配置 - Nginx 场景下检查：
worker_connections（默认 512）、multi_accept on、以及keepalive_timeout是否过短（导致 Locust 频繁建连） - 数据库侧查连接数：
SHOW STATUS LIKE 'Threads_connected';（MySQL）或pg_stat_activity（PostgreSQL），确认是否 hit 了max_connections - Locust 端可临时加连接复用控制：
self.client.headers.update({"Connection": "keep-alive"})，但治标不治本，重点还是调服务端容量
真实压测里最常被忽略的，是 Locust 进程自身的 GC 峰值和内存泄漏 —— 特别是用了自定义 TaskSet 或频繁创建大对象（如 base64 图片体）时，ps aux --sort=-%mem 一眼就能看出异常增长。
