Python Web 性能调优：Worker、连接池与缓存

功能跑通只是第一步，接口慢、并发一高就 502，才是真正让人头疼的。下面是我调优 Python Web 服务的三板斧，都是花小力气、见大效果。

一、Worker 数不是越多越好

用 Gunicorn 跑 FastAPI（配 UvicornWorker）时，Worker 数一般取 CPU 核数 × (1~2)。开太多反而因进程切换和内存竞争变慢。我的生产启动参数大致是这样：

gunicorn app:app -k uvicorn.workers.UvicornWorker \
  -w 4 --threads 2 --bind 0.0.0.0:8000

调之前先看监控：如果 CPU 没满但响应慢，多半是卡在数据库或外部调用，加 Worker 没用，得去查下游。

最隐蔽的坑是连接泄漏：每个请求开一个新连接却不关，连接数很快打满，新请求全在等。用连接池复用连接，并设置合理的上限和超时，问题基本消失。记住：用完的连接要还回去，而不是一直开着。

经验：把“获取连接—查询—释放连接”包成上下文管理器，离开作用域自动归还，从代码层面杜绝泄漏，比靠人记靠谱得多。

图片、JS、CSS 这些静态文件，让 Nginx 直接吐，别绕到 Python 应用里。Nginx 处理静态文件又快又省，把应用进程腾出来干正事。这也是为什么我把后台前端和接口反代都交给 Nginx 统一收口。

像统计看板这种“算一次要查很多表、但短时间内容变化不大”的接口，把结果缓存几秒到几分钟，数据库压力立刻降下来。可以用 Redis，也可以先用进程内缓存顶着，关键是别每次请求都重算。

打开 MySQL 慢查询日志，把超过阈值的 SQL 捞出来，八成能定位到缺索引或写法烂的语句。加对一两个索引，接口可能从几百毫秒掉到几毫秒。

性能优化的顺序永远是：先量再改，改完再量。下一篇讲运维——把前面这些稳定跑起来，并且让管局相信“这个网站有人在管”。