Python全栈项目的部署优化方案

上周帮朋友排查一个电商项目，访问量稍微上来点就直接崩掉。打开服务器监控一看，内存占用95%，CPU直接飙到100%。这种场景在Python全栈项目中实在太常见了——开发阶段跑得飞起，一到部署就各种水土不服。

部署前的性能评估

部署优化不是简单地把代码扔到服务器上。首先得搞清楚项目的瓶颈在哪。Django或Flask项目通常卡在几个地方：数据库连接池、静态文件服务、WSGI服务器配置。有个简单的方法，在本地用ab或wrk做个压力测试，模拟100个并发用户，看看响应时间曲线。

实测发现，默认配置的uWSGI处理200个并发请求时，响应时间从50ms直接跳到800ms。这背后是Python的GIL锁在作祟——单个进程无法真正利用多核优势。

WSGI服务器的调优策略

uWSGI的配置参数直接影响性能。processes数量建议设置为CPU核心数的2-3倍，threads设为2-4。但这不是固定公式，需要根据实际负载调整。有个经验值：4核8G的服务器，配置processes=8, threads=2比较稳妥。

更关键的是max-requests参数。设置成1000-5000，可以定期重启worker进程，避免内存泄漏累积。曾经有个项目因为没设这个值，运行一周后内存占用从500M涨到2G。

数据库连接池的隐藏陷阱

Django的默认数据库配置每个请求都会创建新连接，高并发时直接把数据库连接数撑爆。引入django-db-connections-pool后，连接复用率提升80%。但要注意连接超时设置，太短会导致频繁重连，太长会占用资源。

Redis连接池更是容易忽视的点。每次操作都新建连接，光TCP三次握手就浪费几十毫秒。使用redis-py的连接池后，QPS从800提升到2200。

静态资源的优化技巧

千万别再用Django自带的静态文件服务了。Nginx直接处理静态请求，性能差出几个数量级。配置gzip压缩后，一个1.2MB的JavaScript文件压缩到300KB，加载时间从1.2秒降到400毫秒。

更激进的做法是把静态资源推到CDN。有个电商项目图片很多，用了CDN后，页面加载时间从3秒降到1秒以内，跳出率直接降了15%。

容器化部署的实战经验

Dockerfile里有个细节：把requirements.txt的安装单独作为一层。这样代码变更时不需要重新安装依赖，构建时间从5分钟缩短到30秒。

健康检查配置也很有讲究。简单的curl localhost:8000不够用，应该检查数据库连接和关键接口。曾经有个服务健康检查通过，但数据库连不上，导致流量继续打到故障节点。

部署优化是个持续过程。每次代码更新后都要重新评估性能指标，毕竟新功能可能带来新的瓶颈。现在那个电商项目已经稳定支撑日均10万PV，朋友终于不用半夜起来重启服务了。