uWSGI是Python Web应用生产部署中最常用的应用服务器之一，它实现了WSGI协议，能够将Nginx等前端服务器转发过来的HTTP请求交给后端的Django、Flask等框架处理。合理的配置与持续的优化，直接决定了接口的响应速度和系统的并发承载能力。
uWSGI基础配置解析
在uWSGI中，最核心的配置项是进程与线程模型。通过master参数开启主进程后，uWSGI会生成一个管理进程，负责监控和重启worker子进程，避免单个worker崩溃导致服务不可用。worker数量由processes或workers指定，每个worker可以再开启若干threads来处理请求，形成进程加线程的混合并发模型。
除了并发模型，socket配置决定了uWSGI与前端Web服务器的通信方式。常见的是通过本地Unix socket文件与Nginx对接，例如socket = /tmp/uwsgi.sock，这种方式比TCP端口通信开销更小。同时需要设置chmod-socket让Nginx有读写权限。以下表格列出了新手最容易混淆的几个基础参数：
| 配置项 | 作用 | 推荐初值 |
|---|---|---|
| master | 是否启用主管理进程 | true |
| processes | worker进程数量 | CPU核心数 |
| threads | 每个worker的线程数 | 2到4 |
| socket | 监听地址或文件 | /tmp/uwsgi.sock |
进程与线程优化策略
worker进程数不是越多越好。每个worker都会加载一份Python解释器和应用代码，内存占用随进程数线性增长。一般经验公式是：worker数等于CPU核心数，若应用IO等待多，可适度增加到核心数的一点五倍。线程数则视业务而定，如果是CPU密集型任务，多线程因GIL存在帮助有限；如果是数据库查询类的IO密集型，开两到四个线程能提升吞吐。
另一个关键是lazy-apps参数。默认情况下uWSGI会在master中先导入应用，再fork出worker，这会导致所有worker共享导入时的状态且占用额外内存。设置lazy-apps = true后，每个worker独立导入应用，虽然启动稍慢，但内存更隔离，也方便不同worker加载不同配置。对于内存敏感或需要热更新的场景，这个优化非常实用。
缓冲区与超时参数调优
uWSGI对每个请求设有内部缓冲区，由buffer-size控制，默认常为四万零九十六字节。当请求头或Cookie较大时，默认值会导致网关错误。一般建议将其提升到六万五千五百三十六或更高，尤其是使用了复杂鉴权头或大量Cookie的站点。但也不宜过大，否则容易被恶意请求耗尽内存。
超时类参数决定了连接的忍耐度。harakiri设定单个请求最长处理秒数，超过则强制回收worker，防止慢请求拖垮整个池子。http-timeout则控制与前端通信的空闲断开时间。对外部依赖不稳定的系统，把harakiri设为三十秒左右，既能释放资源又不会误杀正常长任务。配合reload-on-rss限制单个worker内存上限，可让服务长期稳定运行。
监控与日常维护
优化不是一次性的工作。uWSGI自带stats接口，开启stats = 127.0.0.1:9191后，可用工具拉取实时数据，观察worker占用、请求排队情况。如果发现listen队列持续满员，说明进程数不足或后端太慢，需结合上面策略调整。日志方面，logto指定文件并配合logrotate，避免磁盘被写满。
在版本升级或配置变更后，用uwsgi --reload发信号平滑重启，用户无感知。日常可编写脚本定时检查stats中的异常指标，做到问题前置处理。把配置纳入版本库，每次改动有迹可循，也是生产环境必不可少的习惯。