必须用原生异步客户端（如aiohttp.ClientSession）压测异步接口，否则QPS虚高且无法暴露真实瓶颈；需复用事件循环、连接池与协程调度，并正确处理超时、并发控制、异常捕获及任务语义。
直接用同步工具测异步接口，结果会严重失真——比如用 requests 压测一个基于 aiohttp 的服务，测出来的 QPS 可能虚高 3–5 倍，还压不出连接池耗尽、asyncio.TimeoutError 或 Too many open files 这类真实瓶颈。关键不在“并发数量”，而在“是否复用事件循环、连接池和协程调度”。
必须用原生异步客户端发起请求
requests 是阻塞式库，每个请求独占线程/协程，无法模拟异步服务的轻量协程切换与连接复用。真正有效的压测必须用 aiohttp.ClientSession 或 httpx.AsyncClient 这类支持 connection pooling 和 event loop 集成的客户端。
- 避免直接调用 session.get(url)；改用 async with session.get(url) 确保连接自动归还到池中
- 显式设置 timeout=client_timeout（如 aiohttp.ClientTimeout(total=10)），否则超时请求会永久挂起
- 用 asyncio.Semaphore 控制并发上限，防止瞬间创建上万 task 导致 OSError: [Errno 24]
- 捕获常见异常：aiohttp.ClientConnectorError、asyncio.TimeoutError、ClientOSError，避免单点失败中断整个压测流程
任务需匹配异步接口的实际语义
异步接口常分两阶段：提交（立即返回 task_id）+ 轮询状态（异步结果）。压测不能只测提交接口，否则掩盖后端队列和消费瓶颈。
- 先发 submit 请求获取 task_id，再并发轮询 /status?task_id=xxx，模拟真实用户等待路径
- 为每个请求生成唯一 trace_id 或 request_id，便于服务端日志追踪与错误归因
- 轮询逻辑要带退避策略（如指数退避），避免无效高频查询打垮状态接口
- 记录端到端耗时（从 submit 到 status 返回 success），而非仅 submit 响应时间
Locust 中绕过 HttpUser，手管 aiohttp 生命周期
Locust 默认 HttpUser 基于 requests，与 asyncio 冲突。若要用 Locust 做分布式异步压测，必须弃用 HttpUser，改用基础 User 类并自行管理 ClientSession。
- 在 init 中新建独立 event loop（asyncio.new_event_loop()），防止被 gevent hijack
- on_start 中创建 aiohttp.ClientSession，并传入 connector=aiohttp.TCPConnector(limit=100, limit_per_host=30)
- @task 方法声明为 async def，内部用 await self.client.get(...)，且必须 consume 响应体（如 await resp.text()）
- on_stop 中显式 await self.client.close()，否则连接泄漏，多次启动后触发 Too many open files
- 禁用 wait_time = between()；改用 await asyncio.sleep(random.uniform(0.5, 2)) 实现异步等待
监控指标要反映异步特性
同步压测看响应时间、TPS、错误率就够了；异步压测还需关注协程调度延迟、连接池利用率、任务排队时长等维度。
- 客户端侧：统计每秒成功完成的“完整任务数”（submit + 成功 status），即有效 TPS
- 服务端侧：监控消息队列积压量、消费者处理速率、异步任务平均排队时间
- 资源层：观察 Python 进程的 asyncio._runners 数量、loop.time() 与实际 wall clock 偏差（反映事件循环过载）
- 错误分类细化：区分 submit 失败（网关层）、status 超时（后端慢）、status 返回 failed（业务逻辑错）
