1. 项目背景
“618 大促第一分钟，AI 客服就崩了——用户消息发出去 25 秒才收到回复，Nginx 日志里 502 堆积如山。运营总监在工作群里 @我 八次。“小陈事后复盘，发现问题根源不是"机器不够”（4 核 16GB 的服务器 CPU 才用了 15%），而是"不知道瓶颈在哪”。
Dify 是典型的I/O 密集型应用——大部分时间不是在算东西，而是在等：等 LLM API 返回（网络 I/O，2-30 秒）、等数据库查询（磁盘 I/O，5-500ms）、等 Redis（内存 I/O，0.3ms）。CPU 只有 15% 说明 CPU 不是瓶颈——问题一定在某个 I/O 层。
小陈的排查路径是经典的"试错法"：先加了 2 台机器——QPS 没变；然后调大了 Gunicorn Worker——还是没变；最后偶然发现 Message 表 200 万行没有索引，每次查询全表扫描耗时 5 秒——加上复合索引后 QPS 从 22 飙到 180。如果他一上来就用火焰图定位，这个优化只需要 30 分钟，而不是 3 天。
本章不是"给出指令你照做"，而是一套数据驱动的性能优化方法论：测量（火焰图 + 慢日志 + 压测）→ 定位（找到真正的瓶颈层）→ 优化（对症下药，一层一层改）→ 验证（重新压测对比）。
2. 项目设计
小胖：（把 wrk 压测报告往桌上一拍）“大师！wrk 显示 QPS 才 22，P99 延迟 18 秒！用户等 18 秒才收到’你好’两个字，不投诉才怪。