先确认现象和瓶颈所在

接到DRF API性能优化需求时，我不会立刻动代码或改配置。我会先看实际流量特征和慢请求分布。通常我会翻Nginx或应用层日志，找出p99和p50的响应时间，同时确认CPU、内存、数据库连接池和磁盘I/O的利用率。如果响应慢但CPU空闲，大概率是数据库查询或网络等待；如果CPU跑满，可能是序列化或业务逻辑过重。这一步做完，才能决定往哪个方向查。

容易误判的地方

很多人上来就怀疑DRF本身慢，或者盲目加缓存。实际上多数慢查询来自序列化器嵌套太多或ORM的N+1查询。DRF的Serializer默认会递归序列化关联对象，如果用了depth或写死了嵌套字段，一个列表接口可能触发上百条SQL。另一个容易误判的是把Gunicorn工作进程数直接设成CPU核数×2，结果连接数过多导致上下文切换频繁。建议先检查数据库慢查询日志和profiling工具，比如django-debug-toolbar或drf-tracking，确认瓶颈在哪个环节再动手。

建议的处理顺序

按风险从低到高排：第一步，用select_related和prefetch_related优化ORM查询，同时减少Serializer中不必要的嵌套字段。第二步，调整Gunicorn配置——工作进程数设为(2×CPU核数)+1，但需要结合内存和并发量观察；worker-class建议用gevent或uvicorn，前提是代码兼容异步。第三步，对高频读接口加缓存，比如用django-cacheops或手动缓存到Redis，但注意缓存失效策略和一致性风险。第四步，把静态资源（如API浏览界面）和媒体文件交给Nginx处理，避免穿透到应用层。如果改完后响应时间还未达标，再考虑分库分表或读写分离，但那是较重的操作，需要预留回滚计划。

配置或命令示例

Gunicorn启动命令参考：gunicorn myproject.wsgi:application --workers 4 --worker-class gevent --bind 0.0.0.0:8000 --timeout 60 --access-logfile -。其中workers数量需要先做压力测试确认，通常从(2×CPU核数)+1开始，逐步增加直到CPU使用率达到80%左右。如果使用Daphne或Uvicorn跑ASGI，则要调整worker-class为uvicorn.workers.UvicornWorker，并注意在Nginx里配置proxy_set_header Upgrade和Connection头以支持WebSocket。

# Nginx反向代理配置片段
location /api/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_buffering on;
    proxy_buffer_size 4k;
    proxy_buffers 8 16k;
    proxy_busy_buffers_size 32k;
    # 调整超时
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
}

验证方法

每改完一项，我会在预发布环境用wrk或locust压测三个场景：列表接口、详情接口、写接口。观察响应时间、错误率和资源占用是否改善。同时对比改动前后的慢查询日志数量。如果缓存生效，第二次请求响应时间应明显下降。注意压测时要模拟真实流量分布，不要只跑一个接口。如果改完后报错率上升或响应不稳定，应立即回滚上一步改动，检查日志确认是超时、OOM还是锁等待。

后续维护

性能优化不是一次性工作。我建议在部署流水线中加入性能回归测试，用diff工具对比每次部署的API响应时间散点图。另外定期清理过期缓存和日志，避免磁盘写满拖慢I/O。如果出现新版本或流量突增，先按上述确认流程检查瓶颈，再决定是否调整worker数量或扩容。缓存命中率要持续跟踪，一旦命中率低于80%就需要重新设计缓存策略。