使用Locust对Dify的API接口进行高并发压力测试与性能评估的步骤

Dify流式压测需用Locust 2.0+原生支持SSE：继承HttpUser、设host、on_start获取conversation_id/message_id，@task中stream=True逐块解析data:，精准采集TTFB与总耗时并自定义上报。

你需要验证Dify在真实流量冲击下能否稳定支撑数百并发用户的流式对话请求，避免客服机器人在咨询高峰期卡成PPT。这要求压测脚本必须能正确处理SSE分块响应、动态管理认证Token、模拟真实用户思考间隔，并精准采集首字节时间（TTFB）与完整响应耗时。

安装Locust并创建基础测试文件

执行pip install locust安装最新版Locust（务必确认不是1.x旧版本，否则会报AttributeError: 'MyUser' object has no attribute 'client'）。在项目根目录新建locustfile.py，这是唯一必需的入口文件。

文件开头必须导入HttpUser类——Locust 2.0+已弃用TaskSet和User基类，直接继承HttpUser才能获得client属性。

在类定义中【必须显式声明host属性】，哪怕只是占位符如host = "https://your-dify-instance.com"，否则启动时会抛出AttributeError: 'ApiUser' object has no attribute 'host'。

构造Dify专用压测用户类

定义DifyUser类继承HttpUser，设置wait_time = between(1, 5)模拟真实用户输入间隔，避免请求洪峰冲击后端。

在on_start方法中完成登录并提取Token：向/v1/chat-messages接口发送POST请求获取临时会话凭证，注意Dify的API密钥需通过Authorization: Bearer {api_key}传递，而非表单登录。

将返回的conversation_id和message_id存入实例变量self.conversation_id与self.message_id，后续流式请求必须携带这两个参数，否则Dify会拒绝服务并返回400错误。

编写流式接口压测任务

方法一：使用stream=True原生支持SSE

在@task装饰函数中调用self.client.post("/v1/chat-messages", json=payload, stream=True)，payload需包含{"inputs": {}, "query": "你好", "response_mode": "stream"}，这是Dify流式响应的强制模式。

用for line in response.iter_lines()逐行解析SSE数据块，遇到data:前缀时剥离并统计token数量——这能真实反映LLM生成速度，而非仅网络传输延迟。

方法二：手动计算TTFB与总耗时

在发起请求前记录start_time = time.time()，收到第一个data:块时记录ttfb = time.time() - start_time，循环结束后记录total_time = time.time() - start_time。

【TTFB必须在首次收到data:时立即捕获，延迟1毫秒就会导致指标失真】

方法三：注入自定义监控事件

调用events.request_success.fire(request_type="SSE", name="/chat-messages", response_time=ttfb, response_length=0)单独上报首字节时间，再用另一次fire上报完整响应时间，这样能在Web UI中分离观察两个关键指标。

启动压测并实时调参

第一步：运行locust -f locustfile.py --host=https://your-dify-domain.com，确保域名与Dify实际部署地址完全一致，HTTPS证书不匹配会导致连接被拒绝。

第二步：浏览器访问http://localhost:8089，在Web UI中填入虚拟用户数（Users）和每秒新增用户数（Spawn Rate）。

第三步：点击Start Swarming按钮，观察RPS曲线是否平滑上升——若出现锯齿状抖动，说明Dify后端连接池已耗尽，需立即降低并发量或调整服务端keep-alive配置。

第四步：当失败率（Failure %）持续高于5%，暂停压测，检查Dify日志中的503 Service Unavailable或429 Too Many Requests错误，这些是资源瓶颈的明确信号。