ASR/TTS 稳定性测试

本文档用于测试 sherpa-asr-online-server 与 sherpa-tts-server 的上线容量和长稳表现。测试工具位于 onnx-platform/stability-test.mjs，只作为客户端发压和采集数据，不会启动、停止或修改服务。

测试前准备

• 先分别启动 ASR 与 TTS 服务，并确认：
  • GET http://127.0.0.1:10096/health 返回 200。
  • GET http://127.0.0.1:9080/health 返回 200。
  • TTS 流式链路可用时，本机 PATH 中能找到 ffmpeg，或服务配置已指定 mp3EncoderPath。
• 记录测试时的实际配置作为本轮基线（以各服务 config.json 当前值为准；仓库当前值）：
  • ASR：maxSessions=256、sessionPoolSize=48、ioWorkers=8。
  • TTS：workerThreads=48、ttsPoolSize=8、maxQueuedRequests=256。
• ASR 相关模式默认会先调用 TTS POST /tts 生成一段 16kHz mono PCM16 wav，下载到本轮结果目录的 asr-source.wav，再用这段音频推送给 ASR。若要改回手工 wav，使用 --prepare-asr-wav-from-tts false --asr-wav <path>。
• 测试结束时，必须停止本次测试中手动启动的 ASR/TTS 服务。

推荐执行流程

先跑冒烟，确认协议链路和数据落盘：

bun .\onnx-platform\stability-test.mjs --mode smoke --prepare-asr-wav-from-tts true --duration 10s

再跑阶梯容量，每档 15 分钟。1x1 表示 1 条 ASR 长连接 + 1 个 TTS 请求 worker，默认阶梯是 1x1,2x2,4x4,5x4,6x6,8x8。阶梯是否触及 ASR 容量边界取决于当前 maxSessions（仓库当前为 256，默认阶梯不会越界；如需验证 503 保护边界，可临时把 maxSessions 调小到阶梯范围内）：

bun .\onnx-platform\stability-test.mjs --mode capacity --step-duration 15m

如果只想快速定位当前 ASR 保护边界，可先缩短每档时间：

bun .\onnx-platform\stability-test.mjs --mode capacity --step-duration 2m --capacity-steps 1x1,2x2,4x4,5x4

找到稳定上限后，用稳定上限的 70%-80% 做 8 小时长稳。例如容量测试显示 4 路 ASR 会话稳定、5 路开始出现预期 503 保护，可用 3 路通话做长稳：

bun .\onnx-platform\stability-test.mjs --mode soak --calls 3 --duration 8h

也可以拆开单服务测试：

bun .\onnx-platform\stability-test.mjs --mode asr --asr-concurrency 4 --duration 30m
bun .\onnx-platform\stability-test.mjs --mode tts --tts-concurrency 8 --duration 30m

ASR 自动音频准备可按需调整文本、说话人和语速：

bun .\onnx-platform\stability-test.mjs --mode asr `
  --asr-concurrency 4 `
  --duration 1m `
  --asr-tts-text "您好，这是本轮 ASR 压测使用的语音内容。" `
  --asr-tts-speaker-id 0 `
  --asr-tts-speed 1.0

规避 TTS 缓存

如果要测试 TTS 真实合成能力，避免少量固定文本快速命中 wav 缓存，开启中文唯一编号：

bun .\onnx-platform\stability-test.mjs --mode tts --tts-concurrency 4 --duration 30m --unique-tts-text true

混合电话业务压测时也可以规避缓存：

bun .\onnx-platform\stability-test.mjs --mode mixed --calls 6 --duration 30m --unique-tts-text true

开启后，脚本会把每条 TTS 文本变成类似：

您好，这里是智能语音服务测试。 批次二零二六零六零九一六三零零一 编号零零一

批次号来自本轮运行时间，编号按请求递增。这样同一轮内不会因为文本重复命中缓存，下一轮也不容易命中上一轮留下的 wav。

负载模型

• ASR：每个并发会话建立 1 条 WebSocket，发送 metadata，然后按真实时间速率推送 16kHz mono PCM16 wav。默认音频来自本轮开始时 TTS /tts 生成的 asr-source.wav。每轮音频结束后发送 zero-length binary flush，并短暂停顿。
• TTS：按间隔提交短句，按 --stream-ratio 在 /tts 和 /tts-stream 间分配。普通 /tts 会继续 HEAD /wav，默认也会 GET /wav，模拟 FreeSWITCH 播放拉取。
• 缓存口径：默认保留文本重复，用于测试真实业务里的缓存和播放链路；需要压实际合成能力时使用 --unique-tts-text true。
• 混合模式：每个“电话会话”保持 ASR 长连接，同时有 TTS worker 按通话节奏发起播报。

常用参数：

bun .\onnx-platform\stability-test.mjs --mode mixed `
  --calls 6 `
  --duration 30m `
  --tts-interval-ms 15000 `
  --stream-ratio 0.5 `
  --sample-interval-ms 10000

输出数据

默认输出到 onnx-platform/stability-results/<timestamp>/：

• options.json：本轮测试参数。
• asr-source.wav：ASR 相关模式默认由 TTS /tts 生成并下载的推流源音频。
• events.jsonl：逐事件原始明细，适合后续脚本分析。
• metrics.csv：请求/会话级指标，适合 Excel 查看。
• resource-samples.csv：每 10 秒资源快照和 /health 结果。
• summary.json：计数器和延迟分位数摘要。

重点字段：

• ASR：handshake、session_end、final、session_fail、capacity_boundary、read_error。
• TTS：tts_wav、tts_wav_head、tts_wav_get、tts_stream_create、tts_stream_head、tts_stream_get。
• 资源：asrActiveSessions、asrMaxSessions、workerThreads、ttsPoolSize、cpuSeconds、workingSetBytes、threads、handles、wavFiles、wavBytes。

通过标准

• 冒烟：ASR 至少收到 final，TTS /tts 可返回 wav，/tts-stream 的 GET 返回 MP3 数据。
• 阶梯容量：非极限档位不应出现 ASR 异常关闭、TTS 5xx、TTS 503；超过 ASR maxSessions 时出现 ASR 503 属于预期保护边界，脚本会记录为 asr.capacity_boundary，不计为脚本异常。除 503 外的握手失败仍按 asr.session_fail 处理。
• 上限判断：某档位如果 ASR session_end 正常、TTS 请求成功率稳定、p95/p99 与资源曲线可接受，则可视为可承载；首次集中出现 capacity_boundary、TTS 503、持续 5xx、进程资源耗尽或延迟明显失控的档位，应视为超过当前配置上限。
• 8 小时长稳：
  • 两个服务进程不退出，/health 持续可用。
  • ASR activeSessions 能在测试结束后回落。
  • TTS 延迟 p95/p99 不随时间持续恶化。
  • 进程内存、线程、句柄没有单调泄漏趋势。
  • wavBytes 的增长需要结合 server.maxCacheEntries 的 LRU 上限判断；配置为 0 时才不限制条数。

记录建议

保存以下材料用于结论分析：

• 测试命令、服务配置、机器规格、模型名称。
• ASR/TTS 服务 stdout 日志。
• stability-results 目录完整内容。
• 每个阶梯档位的容量判断：成功率、p95/p99、CPU、内存、句柄、wav 增长量。