聊天后端流式压测：让数百条实时回复同时保持畅通
§1 流式聊天压测，测的是持续打开的连接
普通接口通常返回完整结果后就结束请求，聊天流式接口却会保持连接，逐步发送生成的内容。用户看到文字不断出现，服务器则需要持续维护连接、转发数据，并处理随时可能发生的取消与断开。
因此，每秒请求数并不能单独代表流式聊天的承载能力。即使新请求不多，只要每条回复持续很久，后台也可能积累大量活跃连接。压测的目标不是只看接口能否返回成功，而是确认多人同时聊天时，回复仍然及时、完整且可取消。
§2 用回复时长估算需要维持的并发流
可以先做一个简单估算：稳定运行时，平均活跃流数量约等于每秒新建请求数乘以平均流持续秒数。例如，每秒开始十次聊天，每次持续二十秒，平均就会有约两百条流同时存在。
这只是起点，不是容量承诺。长回复、流量突增和用户重试都可能抬高并发。设计测试时，应同时规定新请求进入的速度、回复长度和运行时间，而不是只填写一个“并发两百”。
§3 让压测客户端真正读取令牌流
如果后端使用服务器发送事件（SSE），压测客户端就要持续读取响应，直到收到结束信号或连接关闭。只检查响应头便结束计时，会把仍在生成的回复误当成已经完成。
还要注意，一次网络读取不等于一个令牌，也不一定是一条完整事件。客户端需要按照事件边界解析数据，并确认正常结束。否则，半条回复也可能被统计为成功。
- – 使用短、中、长三类输入和回复长度，接近真实聊天分布。
- – 为每条流记录开始、首次内容到达、最后内容到达及结束时间。
- – 区分正常结束、主动取消、超时和意外断流，避免混成同一类失败。
§4 先测模拟流，再接入真实模型
第一轮可以使用模拟上游，按照固定间隔发送内容。这样更容易发现聊天后端自身的问题，例如连接数限制、内存增长、代理缓冲，或者数据已经到达后端却迟迟没有转发。
第二轮再接入真实模型，观察上游生成速度、配额和网络波动带来的影响。需要统一接入时，可以考虑面向流式响应、按令牌付费的 Fluxio，通过兼容 OpenAI 风格的客户端接入，并选择 Gemini 2.5 Flash 等模型作为固定测试对象。
两轮测试应分开报告。真实模型变慢，不一定是你的服务器变慢；模拟流表现良好，也不代表完整链路已经通过验证。真实调用还会产生费用，应提前设置预算和停止条件。
§5 同时观察首字等待、输出停顿和资源占用
用户最容易感知的是多久开始出现文字，以及输出途中是否频繁停顿。建议从客户端发起请求开始，测量首次有效内容到达的时间，并单独记录整条回复的完成时间。
- – 查看首个令牌延迟的中位数和第九十五百分位，避免平均值掩盖慢请求。
- – 记录内容到达间隔和异常长停顿，检查回复是否成批出现而非持续输出。
- – 同步观察活跃连接、内存、处理器负载、文件描述符及限流响应。
- – 检查压测机器自身的连接和网络能力，防止把发压端瓶颈误认为服务端瓶颈。
§6 逐级加压，并验证慢读与取消后的清理
先用少量连接确认功能，再逐级增加负载，每一级都保持足够时间观察稳定状态。达到目标并发后，还要进行持续运行测试，检查内存是否不断上涨、连接是否无法释放。
别漏掉慢客户端和中途退出的用户。让部分客户端缓慢读取，观察服务端是否无限积压待发送数据；主动取消一部分请求，确认后端及时清理资源，并按设计取消上游生成。对限流和断流，也应验证退避策略，避免立即重试造成更大拥堵。
最终可用容量，应是满足体验指标、错误率和资源余量要求的负载，而不是服务器崩溃前的最高连接数。保存测试条件与结果，每次修改转发逻辑、代理配置或模型后，都能用同一套场景重新验证。
欢迎注册 Fluxio，开始验证你的流式聊天链路。