FastAPI接口从1.2s优化到85ms:一次真实性能瓶颈的定位与调优记录
线上一个FastAPI接口P99响应时间飙到1.2s,QPS只有120。我用py-spy采样定位到瓶颈在SQLAlchemy的N+1查询和缺失的缓存层,通过加索引、改批量查询、引入Redis缓存,最终P99降到85ms,QPS提升到1400+。本文记录了完整的profiling过程、优化代码和压测对比数据,涉及FastAPI 0.110、SQLAlchemy 2.0、Redis 7.2。

Digitalbuilder,记录从构想到上线的过程,技术方向以软件工程为主。持续整理问题排查与调试、代码实现与工程实践和可复用的工程方法;坚持先理解原理,再讨论工具。
线上一个FastAPI接口P99响应时间飙到1.2s,QPS只有120。我用py-spy采样定位到瓶颈在SQLAlchemy的N+1查询和缺失的缓存层,通过加索引、改批量查询、引入Redis缓存,最终P99降到85ms,QPS提升到1400+。本文记录了完整的profiling过程、优化代码和压测对比数据,涉及FastAPI 0.110、SQLAlchemy 2.0、Redis 7.2。
在业务语义理解任务中,直接微调ChatGLM2-6B需要约24GB显存(batch_size=16, seq_len=512),而使用QLoRA(4-bit NormalFloat + Double Quantization + PEFT)后,显存占用降至6.2GB,训练速度仅下降18%。本文记录从数据清洗到loss收敛的全过程,包含两次OOM的排查与解决,以及LoRA rank=8 vs ran
本文分享一个真实项目中的docker-compose.yml配置,包含Nginx、Spring Boot、PostgreSQL、Redis四个服务。通过自定义网络实现服务隔离,使用volume持久化数据库和日志,利用healthcheck和depends_on条件控制启动顺序。解决了一个困扰我两天的服务启动竞态问题,最终将服务启动时间从原来的90秒压缩到35秒,并保证了100%的启动成功率。