SIP测试-03-FreeSWITCH性能测试怎么做

发表于 分类于 本文字数： 2.9k 阅读时长 ≈ 10 分钟

第一次做 FreeSWITCH 性能测试时，目标都写得很直接：

  • 看能扛多少并发
  • 看 CPS 能打多高
  • 看电话能不能大量打通

这些目标当然都对，但如果测试设计只停留在这一层，最后很容易得到一堆不太能用的结果：

  • 屏幕上数字很多，但不知道自己到底在测什么
  • 呼叫失败了，但不知道是账号、路由、媒体还是下游服务先出问题
  • FreeSWITCH 指标看起来不算差，但全链路就是不稳定
  • 明明是脚本或配置问题，最后却被写成 FreeSWITCH 性能瓶颈

所以更准确地说的 FreeSWITCH 性能测试，重点不是“把电话打起来”，而是把下面这几件事讲清楚：

  • 这次到底是在测哪一层能力
  • FreeSWITCH 在整条语音链路里承担了什么角色
  • 哪个指标最先说明它开始退化
  • 当前问题是不是它的主责任，而不是别的层带出来的伴生现象

一、做 FreeSWITCH 性能测试之前，先把被测对象说清楚

很多语音压测失败，不是因为工具不行，而是因为测试对象一开始就没定义清楚。

如果测试对象是 FreeSWITCH，通常可以先拆成下面几类：

1. 注册能力

测试的是：

  • 大量账号注册时认证和注册状态是否稳定
  • 注册速率上来以后，sofia profile 是否先出异常

2. 呼叫建立能力

测试的是：

  • INVITE -> 180/183 -> 200 -> ACK 是否稳定
  • 拨号计划、路由和桥接能力是否能承受目标流量

3. 通话保持与挂断能力

测试的是：

  • 已建立通话在持续一段时间后是否仍然稳定
  • BYE 和结束清理是否正常

4. 信令 + 媒体能力

测试的是：

  • FreeSWITCH 不只是能接通，还能不能稳定桥接媒体
  • RTP、编解码、媒体时长是否会把资源进一步拉高

5. 作为全链路节点的承压能力

测试的是：

  • 它在接入外部网关、机器人服务、识别服务时，是否会成为最先拖垮整条链路的点

这一步非常关键。
因为如果你自己都没说清楚“这次到底测 FreeSWITCH 的哪一层能力”，后面的结果几乎一定会混。

二、不建议一上来就做“整套大压”，而是先拆 4 个阶段

如果要设计一轮 FreeSWITCH 性能测试，通常会按下面顺序推进。

阶段 1：注册摸底

先回答：

  • 注册脚本能不能稳定跑
  • 401/407 是否符合预期
  • 账号池和密码是否都正确

阶段 2：纯信令呼叫摸底

先回答：

  • 路由和拨号计划是否正确
  • 主叫、被叫、桥接逻辑是否走通
  • 高并发下失败码从哪一类开始抬头

阶段 3：加入媒体

再回答：

  • FreeSWITCH 桥接媒体时资源变化如何
  • 是信令先退化，还是媒体上来后才开始退化

阶段 4：加入外部服务或全链路

最后才回答：

  • 整条电话系统承压时，FreeSWITCH 还是不是主瓶颈
  • 它是问题源头，还是被下游拖慢的中间层

这个顺序的价值在于：

  • 每一层都能做独立结论
  • 问题出现时更容易缩小范围
  • 不会把“FreeSWITCH 问题”和“整条语音链路问题”混为一谈

三、做 FreeSWITCH 性能测试时，比总数字更重要的是几个拐点

最常见的问题是：

  • FreeSWITCH 能扛多少 CPS
  • 最大并发通话是多少

这些数字当然重要，但真正有价值的结论通常不是一个单点值，而是几个拐点。

例如：

  • 在什么 CPS 之前注册和呼叫都处于健康区
  • 从什么点开始 480/486/500/503 明显增加
  • 从什么点开始通话建立成功率下降
  • 从什么点开始媒体接通率或挂断稳定性变差

所以更愿意把结论写成：

  • 30 CPS 以内稳定
  • 50 CPS 开始出现少量失败码
  • 80 CPS 后接通率明显下降
  • 加入媒体后拐点提前出现

这种表达比“最大扛到 100 CPS”更有决策价值。

四、更常用的一套观测点

做 FreeSWITCH 性能测试时，通常会同时准备 4 组观测面。

1. SIPp 执行面

主要看：

  • CPS / 呼叫发起速率
  • 当前并发通话数
  • 失败码分布
  • trace_err 和 trace_msg 中的异常模式

2. FreeSWITCH 进程和会话面

主要看：

  • 会话数
  • 每秒新建会话趋势
  • 进程 CPU / 内存
  • sofia profile 状态
  • 通话建立和释放是否及时

3. 系统资源面

主要看：

  • CPU
  • 内存
  • 文件句柄
  • 网络连接
  • RTP / SIP 端口使用情况

4. 下游依赖面

如果接了网关或服务，还要看：

  • 外部网关状态
  • 机器人或语音服务响应
  • 数据库或配置服务是否开始拖慢链路

不建议只看一张 SIPp 屏幕图。
因为那样你只能看到“结果不好”，很难看到“是谁先变坏”。

五、更适合的一套最小执行骨架

如果是一次新的 FreeSWITCH 性能测试，执行流程通常可以先收成这样的骨架：

阶段 目标 典型动作 关键观察
阶段 1 注册验证 主叫/被叫批量注册 注册成功率、挑战码
阶段 2 单通话验证 单主叫 + 单被叫呼叫 报文链路完整性
阶段 3 小并发摸底 10-30 CPS 失败码、路由稳定性
阶段 4 中高并发 50 CPS+ 接通率、会话数、资源
阶段 5 加媒体或全链路 RTP / 外部服务接入 拐点是否前移

一个更接近现场的执行节奏通常是：

1
注册验证 -> 单链路呼叫 -> 小并发纯信令 -> 中并发纯信令 -> 加媒体 -> 加全链路

这个顺序看起来保守，但特别适合真实项目。
因为你越早把问题拆清，后面越不容易浪费时间。

六、正式压测前，先过一遍环境检查表

FreeSWITCH 性能测试最怕环境没收好，结果把环境问题写成性能问题。

通常会先确认下面这些项：

检查项 目的
账号池是否已准备 避免注册或呼叫因账号错误失败
拨号计划和号码范围是否对齐 避免路由假失败
ACL / 白名单是否已放通 避免请求被拦截
max-sessions、sessions-per-second 是否匹配测试目标 避免配置先卡死
SIPp 压测机句柄和端口是否足够 避免工具侧先顶住
日志级别和 trace 策略是否合理 避免日志本身拖垮执行

这张表看起来朴素，但特别有用。
因为 FreeSWITCH 性能测试里，前置配置问题真的非常常见。

七、真实案例型段落：一次“现场都判断是 FreeSWITCH 扛不住，结果主因却不是它”的排查

场景

一次电话系统压测里，目标是验证 FreeSWITCH 在较高并发呼叫下的表现。
现场一开始很快出现了明显异常：

  • 接通率下降
  • 失败码开始增多
  • 部分通话建立慢

团队最初的判断很一致：

  • 这轮压测的对象是 FreeSWITCH
  • 所以问题大概率就是 FreeSWITCH 扛不住了

执行

当时执行方式已经进入较高强度：

  1. 主叫和被叫都完成注册
  2. 主叫侧持续发起较高 CPS 呼叫
  3. 被叫和外部服务也一起参与
  4. 现场同时观察 SIPp 结果和基础监控

现象

表面现象看起来很像 FreeSWITCH 出问题：

  • 呼叫成功率变差
  • 延迟上升
  • 部分失败码开始集中出现

但一个不太对劲的地方是：

  • FreeSWITCH 进程资源虽然上涨，但并没有先出现明显打满
  • 某些轮次里，信令能建立，但后续链路却开始拖长

排查

我当时没有直接接受“就是 FreeSWITCH 顶不住”这个结论，而是按顺序拆：

  1. 先看纯信令层是否已经明显失败
  2. 再看失败码更像路由、占线还是服务异常
  3. 对齐 FreeSWITCH 资源曲线和失败出现时间
  4. 再看下游服务响应是否在同一时间窗口开始抖动

这一轮排下来，真正更早出现异常的不是 FreeSWITCH 本身，而是下游服务响应开始变慢，导致：

  • 呼叫建立后的后续动作变慢
  • 整体链路时长变长
  • 会话占用时间被拉长
  • 最后反过来把 FreeSWITCH 会话压力继续放大

也就是说：

FreeSWITCH 后面也变差了，但它更像被整条链路拖进风险区，而不是最早的主瓶颈。

修复

修复动作不是盲目给 FreeSWITCH 加资源，而是分两步：

  1. 先把纯信令层和全链路层测试结果拆开
  2. 优先处理下游服务响应和链路时长问题，再回头复测 FreeSWITCH

拆开后很快发现：

  • 纯信令层的 FreeSWITCH 承压能力其实比最初判断高
  • 真正让整条链路崩得更快的，是下游服务把通话时长和会话占用拉长了

这个案例对我很重要，因为它说明：

做 FreeSWITCH 性能测试时，最怕的不是它真的有瓶颈，而是你过早把所有问题都归到它头上。

八、更常用的一套排查顺序

如果现场发现呼叫成功率下降，可以按下面顺序排：

  1. 先确认是注册失败多了，还是呼叫建立失败多了
  2. 再看失败码分布是路由类、鉴权类、占线类还是服务异常类
  3. 再对齐 FreeSWITCH 会话数、CPU、内存和失败出现时间
  4. 如果加了媒体或外部服务，再看是不是链路时长被拉长
  5. 最后再判断 FreeSWITCH 是主因、次因还是伴生现象

这套顺序可以明显减少误判。

九、做完 FreeSWITCH 性能测试后，更希望输出什么结论

如果要写报告，通常不会只写：

  • FreeSWITCH 最大支持多少并发

更想写成下面这种形式：

  • 在纯信令场景下，30 CPS 以内稳定，50 CPS 开始出现少量失败码
  • 加入媒体后，退化拐点明显前移，说明桥接媒体带来的资源成本不能忽略
  • 在全链路模式下，最先退化的并不是 FreeSWITCH 本身，而是下游服务导致通话占用时长放大
  • 当前安全工作区、风险区和建议优化方向分别是什么

这种结论才更适合拿去做：

  • 容量评估
  • 架构讨论
  • 下轮优化优先级排序

结语

做 FreeSWITCH 性能测试，真正重要的不是把 SIPp 参数配到多大，而是先搞清楚自己到底在测：

  • 注册
  • 呼叫建立
  • 通话保持
  • 媒体桥接
  • 还是整条语音链路

只有把对象拆清、阶段拆清、观测点拆清，FreeSWITCH 性能测试的结果才会真正有判断价值，而不是只留下一个看起来很热闹的 CPS 数字。