4. SDN控制器性能基准测试

SDN控制器的性能基准测试，本质上是在受控条件下回答三个问题：控制器每秒能处理多少控制请求、每个请求要等多久、在大量交换机或主机同时接入时性能如何退化。这三个问题分别对应吞吐量、延迟和并发连接数三类核心指标。理解它们的定义边界与测量方法，是设计可复现基准测试的前提。

吞吐量：区分请求吞吐与拓扑收敛吞吐

吞吐量通常定义为控制器在单位时间内成功处理并返回响应的控制请求数量，单位是 requests/s 或 events/s。这里必须明确“成功处理”的判定口径：只有控制器返回了正确响应、且响应内容与预期一致，才计入吞吐量；超时、错误码、响应内容不符的请求应单独统计为失败，不能混入吞吐量分子。

在SDN场景中，吞吐量至少有两种测量对象。第一种是控制通道请求吞吐，典型代表是 Packet-In 消息处理速率：数据平面交换机在流表未命中时上送 Packet-In，控制器执行路由计算或流表下发后返回 Packet-Out/Flow-Mod。第二种是拓扑收敛吞吐，即控制器在拓扑变化后完成全网视图更新与流表重下发的能力，通常用“拓扑事件数/秒”或“收敛完成时间”间接衡量。两者不能互相替代：一个控制器可能 Packet-In 处理很快，但在大规模拓扑变更时收敛缓慢。

测量吞吐量的常用方法是恒定负载法与阶梯升压法。恒定负载法以固定速率持续发送请求，观察成功率与响应时间是否稳定；阶梯升压法则从较低速率开始，每隔固定时间（如10秒）提升一档速率，直到成功率跌破阈值（例如99%）。此时的最高稳定速率即为该配置下的吞吐量上限。示例参数：以 Cbench 类工具向控制器发送 Packet-In，初始速率 1000 req/s，每档增加 1000 req/s，若在 8000 req/s 时成功率降至 97%，则记录 7000 req/s 为稳定吞吐量，并注明测试拓扑规模、控制器线程数、JVM 堆大小等条件。

延迟：从单请求时延到尾部时延

延迟指从控制器收到请求到发出响应所经历的时间，单位通常为毫秒或微秒。基准测试中不能只报告平均延迟，因为平均值会掩盖长尾。建议同时记录 P50、P95、P99 以及最大值。P99 延迟对控制平面尤为重要：当网络出现突发故障时，少量慢请求可能直接导致流表下发滞后，进而引发数据面丢包。

延迟测量有两种基本方式。闭环测量由测试工具发送请求并等待响应，用本地时间戳计算往返时延，实现简单，但包含测试工具与控制器之间的网络传输时间。开环/打点测量则在控制器内部关键路径插入时间戳，分别记录请求入队、业务处理、流表下发完成等时刻，能拆解延迟构成，但需要修改控制器代码或使用其内置指标接口。工程上常先用闭环测量获得端到端延迟，再用控制器自身的 metrics（如 ONOS 的 FlowObjective 统计、OpenDaylight 的 RPC 监控）定位瓶颈在排队、计算还是南向写回。

测量时需固定请求类型与负载大小。例如统一使用 128 字节的 Packet-In 载荷，避免因报文大小变化导致延迟不可比。若控制器启用了批量流表下发（bundle），还应区分单条 Flow-Mod 延迟与 bundle 提交延迟。

并发连接数：控制通道容量与状态规模

并发连接数衡量控制器同时维持的南向连接数量，典型对象是 OpenFlow 交换机连接。它不同于 HTTP 并发连接：每个交换机连接上还承载着握手状态、端口状态、流表状态和周期性 Echo 保活。因此，并发连接数测试必须同时观察连接建立成功率、连接维持时间和内存占用。

测量方法是使用交换机模拟器（如 Mininet 配合自定义脚本、OFPTest、或商业测试仪）逐步建立 N 条 OpenFlow 连接，每条连接完成握手并周期性发送 Echo Request/Reply。记录三个关键点：最大稳定连接数（所有连接保持活跃且 Echo 无超时）、连接建立速率（connections/s）、每连接内存开销（控制器进程 RSS 增量除以连接数）。示例：某控制器在 2000 条连接时 RSS 为 1.2 GB，4000 条时为 2.1 GB，则每连接约增加 0.45 MB；若继续增加到 6000 条时出现大量 Echo 超时，则最大稳定连接数应记录在 4000～5000 之间，并注明测试持续时间（如 10 分钟）。

指标关系与测试设计要点

三类指标并非独立。吞吐量上升通常伴随延迟上升；并发连接数增加会消耗控制器内存与线程资源，进而拉低吞吐量、抬高延迟。因此基准测试应至少给出“吞吐量—延迟”曲线和“连接数—吞吐量”曲线，而不是单一数值。测试报告中必须固定以下条件：控制器版本与配置、JVM/运行时参数、南向协议版本、测试工具与版本、请求类型与大小、拓扑规模、测试持续时间、成功率阈值。缺少这些条件，任何吞吐量或延迟数字都不可比。

可复用的基准测试记录表

为了让不同轮次的测试结果可比较，建议每次测试填写一张固定字段的记录表。以下字段直接对应上述三类指标，可根据实际控制器和工具调整取值。

实际执行时，建议先做单变量测试：固定连接数测吞吐—延迟曲线，再固定请求速率测连接数上限，最后在接近上限的组合条件下做稳定性观察。任何一项指标脱离其余两项单独报告，都容易得出误导性结论。例如“吞吐量 10000 req/s”若未说明此时 P99 延迟已超过 200 ms、或连接数仅为 10，则对工程选型几乎没有参考价值。