Python并发性能评估需区分吞吐量（单位时间任务数）与延迟（P50/P90/P99响应时间），threading、multiprocessing、asyncio各适用于不同场景：CPU密集型首选multiprocessing，I/O密集型推荐asyncio；须用locust等工具压测，避免阻塞调用与资源滥用。
Python并发性能评估的核心在于区分吞吐量（Throughput）和延迟（Latency）这两个关键指标，并理解它们在不同并发模型（如threading、multiprocessing、asyncio）下的实际表现。单纯提升线程数或协程数不一定改善整体性能，反而可能因上下文切换、GIL争用或I/O调度瓶颈导致延迟升高、吞吐下降。
吞吐量：单位时间完成的任务数
吞吐量反映系统处理能力，常用单位是“请求/秒”（RPS）或“任务/秒”。它受CPU利用率、I/O等待、资源竞争等多因素影响。
- 计算方式：总完成任务数 ÷ 总耗时（建议取稳定运行阶段的平均值，排除预热和收尾波动）
- 对CPU密集型任务，multiprocessing通常比threading吞吐更高（绕过GIL）；asyncio在此类场景无优势，甚至因事件循环开销略降吞吐
- 对I/O密集型任务（如HTTP请求、数据库查询），asyncio和threading吞吐接近，但asyncio内存占用更低、可支撑更高并发连接数
- 注意瓶颈转移：当数据库连接池或API限流成为瓶颈时，增加Python并发度不会提升吞吐，需配合后端扩容或重试退避策略
延迟：单个任务的响应时间分布
延迟关注用户体验和系统稳定性，需看P50（中位数）、P90、P99等分位值，而非仅平均延迟。高并发下延迟常呈长尾分布，少量请求可能严重拖慢P99。
- threading在I/O密集场景易因线程切换和GIL间歇阻塞，导致P99延迟跳升；asyncio通过单线程事件循环避免线程调度开销，P90+更平稳
- multiprocessing虽规避GIL，但进程创建/IPC通信成本高，短任务下平均延迟反而高于threading或asyncio
- 真实压测时务必使用固定并发数 + 持续时间（如100并发持续60秒），而非“发完即止”，否则无法暴露排队积压导致的延迟劣化
实操建议：用标准工具做有效对比
避免手写for循环测time.time()——它无法模拟真实并发压力，也难以分离网络、DNS、服务端等因素。
立即学习“Python免费学习笔记（深入）”；
- 推荐工具组合：locust（定义用户行为+分布式压测） + aiomonitor（asyncio运行时监控） + py-spy（采样式CPU/调用栈分析）
- 基准测试前关闭无关服务，绑定CPU核心（taskset）、限制内存（ulimit），减少环境噪声
- 每次只改一个变量：比如对比threading vs asyncio时，保持相同HTTP客户端（如httpx同步/异步版本）、相同超时与重试逻辑、相同服务端部署配置
- 记录关键指标：QPS、平均延迟、P95延迟、错误率、Python进程CPU/内存占用、系统负载（load average）
常见误区与调试线索
很多“并发变慢”问题其实和代码写法强相关，而非模型本身缺陷。
- asyncio中混用阻塞调用（如time.sleep、requests.get、sqlite3.execute）会阻塞整个事件循环，P99延迟陡增——应改用asyncio.sleep、httpx.AsyncClient、aiosqlite等原生异步方案
- threading中未限制线程池大小，导致创建数千线程，触发系统级调度风暴——建议用concurrent.futures.ThreadPoolExecutor(max_workers=20)显式控制
- multiprocessing共享状态滥用（如频繁访问Manager.dict或Queue），引发IPC锁竞争——优先用进程隔离数据，必要时用multiprocessing.Value或Array做轻量共享
- 观察系统指标先于Python指标：若top显示CPU使用率不足50%，但吞吐上不去，大概率是I/O等待或外部依赖瓶颈，不是Python并发模型的问题
