FastAPI压测QPS从180到1600:Profile与查询缓存调优记
一个真实业务接口,单次请求需聚合12张分表数据并执行复杂过滤,初始压测QPS仅180,P99延迟达2.1秒。通过cProfile与py-spy定位到CPU热点集中在SQLAlchemy ORM的逐行对象映射和N+1查询上;改用原生SQL + `fetchall()`后QPS提升至520;再引入Redis二级缓存(TTL 60s)与Gunicorn多Worker(4进程)后,最终QPS稳定在1600

日常收集工具、经验和可复用的方法。关注技术学习与项目实践,主要分享踩坑过程复盘、知识体系搭建和日常踩坑;坚持先理解原理,再讨论工具。愿与认真做事的人一起长期成长。
一个真实业务接口,单次请求需聚合12张分表数据并执行复杂过滤,初始压测QPS仅180,P99延迟达2.1秒。通过cProfile与py-spy定位到CPU热点集中在SQLAlchemy ORM的逐行对象映射和N+1查询上;改用原生SQL + `fetchall()`后QPS提升至520;再引入Redis二级缓存(TTL 60s)与Gunicorn多Worker(4进程)后,最终QPS稳定在1600
当团队从20人扩张到120人,原有单一主干分支策略导致发布前代码冻结长达3天,紧急修复频繁污染特性分支。我们结合GitFlow与TrunkBased设计了一套混合工作流,通过分支命名规范、自动化的Code Review门禁(基于GitLab 15.8+Merge Request Approvals)以及Jenkins Pipeline(2.4.3)的CI/CD集成,将发布周期从周缩短到天,线上缺陷