Locust压测要准，必须用self.client发请求、合理设users/spawn-rate、显式标记业务失败；响应时间不准需结合py-spy和火焰图定位，瓶颈常在连接池、SQL或下游依赖。
Locust 能压出真实瓶颈，但前提是脚本写对、参数设稳、指标看准——压测翻车八成不是服务扛不住，而是 Locust 自己先崩了或统计失真。
Locust 脚本怎么写才不漏统计、不绕过框架
很多人用 requests 发请求，结果 RPS 归零、response time 不计入统计，因为 Locust 只监控 self.client 的调用。
-
HttpUser必须继承，不能用旧版Locust或自定义User类，否则self.client不存在 - 所有 HTTP 请求必须走
self.client.get()/post()等，别用requests、urllib等第三方库 - 路径别拼接完整 URL，写相对路径：
self.client.get("/api/v1/users")，host在类上统一设 - 认证头统一在
on_start里设：self.client.headers = {"Authorization": "Bearer xxx"}，避免每个请求重复构造 - 业务级失败要手动标记：接口返回
200但 body 里"code": 500，得用catch_response=True+response.failure("xxx")
--users 和 --spawn-rate 怎么配才不触发本地资源瓶颈
设 1000 用户不等于产生 1000 并发连接——它取决于你的 wait_time 和任务耗时。盲目拉高参数，最先 OOM 的往往是 Locust 进程本身。
-
--users是目标并发用户总数，不是 QPS；实际 QPS ≈users / avg_response_time_sec -
--spawn-rate建议从1或2开始，观察 Web UI 的 “Users” 曲线是否平滑上升；突增易导致ConnectionRefusedError或 DNS 超时 - 本地运行时，
ulimit -n查文件描述符上限，默认常为1024；--users > 500就可能撞限，需改大（如sudo ulimit -n 65536） - 分布式模式下：
--master不发压，只调度；--worker才真正发请求；worker 数量 ≠ 并发数，总并发由--users决定并均分给所有 worker
响应时间不准、错误率虚高，问题出在哪
Locust 默认只测“发请求到收到响应头”的延迟，但业务卡点往往在 DB 查询、Redis 读取或下游 API，这些它完全不感知。
立即学习“Python免费学习笔记（深入）”；
- 响应时间统计不含 DNS 解析、TCP 建连、TLS 握手等前端耗时（除非你用
tcpdump或 eBPF 抓包） - HTTP
200一律算成功，哪怕后端返回{"code": 500, "msg": "库存扣减失败"}；必须用with self.client.get(...) as resp:显式检查 body - 单次请求内多个子操作（如先查 DB 再写缓存）的耗时无法拆解，需配合
cProfile或py-spy定位热点函数 - 火焰图里看到某函数占 40% CPU，但该函数调用链中可能有阻塞 I/O —— 这说明协程没让出控制权，
gevent.monkey.patch_all()没生效或 patch 不全
压测中发现瓶颈，下一步该查什么
别急着加机器或调参。真实瓶颈往往藏在三个地方：连接池、SQL、下游依赖。Locust 只告诉你“慢”，得靠其他工具定位“为什么慢”。
- DB 层：开
pg_stat_statements（PostgreSQL）或slow_query_log（MySQL），看是否出现未走索引的SELECT *或 N+1 查询 - Python 层：用
py-spy record -o flame.svg --pid $(pgrep -f locust)采样，火焰图里若json.loads或sqlalchemy.orm.session占比高，就是反序列化或 ORM 开销过大 - 连接池：检查
SQLAlchemy的pool_size和max_overflow，压测时若大量请求卡在pool.acquire，说明连接池太小 - 下游依赖：用
tcpdump或Wireshark抓包，确认是目标服务响应慢，还是中间网关/负载均衡器转发延迟高
最常被忽略的是：Locust 自身的协程调度是否健康。如果 gevent patch 不全（比如漏了 ssl 或 subprocess），某些操作会退化为同步阻塞，拖垮整个压测进程——这种问题不会报错，只会让 RPS 上不去、响应时间毛刺多。
