Python并发压测核心是模拟真实请求节奏，需先分析业务场景，选用Locust等合适工具，关注95%响应时间、错误率、I/O阻塞、文件描述符、数据库连接等5大指标，通过渐进式多轮测试确定系统容量水位。
用Python做并发压测，核心是模拟真实请求节奏
别一上来就堆线程或协程，先想清楚业务场景：用户是短时爆发还是持续匀速访问？接口响应时间波动大不大？数据库和缓存有没有连接池瓶颈？Python压测不是比谁QPS高，而是看系统在什么并发量下开始抖动、超时、报错——这才是容量水位的关键信号。
选对工具：locust比threading更贴近真实用户行为
原生threading或asyncio写压测脚本容易误判。比如用1000个同步线程发请求，实际可能因GIL或TCP连接耗尽卡死，但这不代表线上真实压力。Locust自带用户模型（User）、任务分布（TaskSet）和Web监控面板，能按RPS或用户数动态调节负载，还能记录响应时间分布、失败率、每秒请求数等关键指标。
- 安装简单：pip install locust
- 写一个最小可运行脚本：继承HttpUser，定义@task方法，用self.client.get()发请求
- 启动命令：locust -f script.py --host=https://api.example.com，打开http://localhost:8089配并发用户数和spawn速率
压测中必须盯住的5个指标
光看平均响应时间没意义。要结合分位值和错误日志交叉分析：
-
95%响应时间突增：说明部分请求已排队或资源争抢严重，比平均值更早暴露瓶颈
-
错误率>1%：关注HTTP 5xx、连接超时（ConnectionTim
eout）、ReadTimeout，不是所有错误都记为“失败”，得看业务语义
-
服务端CPU/内存平稳但QPS卡住：大概率是I/O阻塞（如DB慢查询、Redis连接池满、磁盘IO饱和）
-
客户端出现大量OSError: [Errno 24] Too many open files：Linux文件描述符不足，需调高ulimit -n，否则压测本身成瓶颈
-
数据库连接数打满、慢查询陡增：配合SHOW PROCESSLIST或慢日志分析，确认是不是没走索引或事务过长
容量解析不是一次压完就结束
真正的容量结论来自多轮渐进式测试：
- 从50并发起步，每轮+50，每轮稳压3分钟，观察指标拐点
- 在疑似瓶颈点（比如95%RT翻倍处）延长压测时间至10分钟，看是否持续恶化还是短暂抖动
- 做一次“降载测试”：从高并发突然减到一半，观察系统能否快速恢复，判断是否有资源泄漏（如未关闭的DB连接、缓存未释放）
- 把结果整理成容量报告：明确写出“当前部署下，支持稳定服务的最大并发用户数为XXX，对应QPS约YYY，临界点出现在ZZZ指标异常时”
eout）、ReadTimeout，不是所有错误都记为“失败”，得看业务语义