上一篇重点介绍了《SDN控制器测试专题四:Floodlight南向接口测试报告(下)》，给出了控制器的功能测试结果。本篇将根据确定的性能测试项，对floodlight控制器性进行逐项测试验证，并会给出测试结果。

1 测试目的

验证floodlight v1.0控制器的以下几个性能情况：

• 验证控制器支交换机上线的最大规模；
• 验证控制器支持的交换机上线的最佳数量；
• 验证控制器流表下发的速度；
• 验证控制器流表下发时延；
• 验证控制支持的最大流表数量；
• 验证控制器mac地址的学习速度；
• 验证控制器在大规模交换机上线情况下的网络拓扑更新速度；

2 性能测试的必要性

控制器负责整个SDN网络的集中化控制，肩负着掌控全网视图，改善全网资源的重要作用。但由于控制能力的集中化，也就意味着控制器很容易成为未来全网的性能瓶颈。为了防患于未然，进行控制器性能测试，全面了解控制器产品的性能状况，提供可靠的性能指标，显得尤为重要。

3 性能瓶颈分析

SDN控制器通过南向网络控制器技术对整个网络中的设备进行了集中化的管控与调度。包括链路发现，拓扑管理，策略制定和表项下发。

3.1 SDN控制器的工作流程

SDN控制器的工作流程如下：

1）控制器与交换机建立ofchannel通道，控制器通过ofchannel控制和管理交换机。
2）当交换机收到一个数据包且流表中没有匹配条目，交换机会将数据包封装在packet_in消息发送给控制器，此时数据包会缓存在交换机中等待处理。
3）控制器收到packet_in消息后，可以发送flow_mod消息向交换机写一个流表项，并且将flow_mod消息中buffer_id字段设置为packet_in消息中的buffer_id值。从而控制器向交换机写入了一条与数据包相关的流表项，并且指定该数据包按照该流表项的action列表处理。但是并不是所有的数据包都需要向交换机中添加一条流表项来匹配处理，网络中还存在多种数据包，它出现的数量很少（如ARP,IGMP等），以至于没有必要通过流表项来指定这一类数据包的处理法，此时控制器可以使用packet_out消息，告诉交换机某一个数据包如何处理。

3.2 性能瓶颈分析

通过分析sdn网络的工作流程，可知控制器通过响应packet_in消息发送packet_out/flow_mod消息的速度是非常重要的，它的快慢直接影响了控制器拓扑发现，流表下发，mac地址学习能力，甚至整个网络的性能。而且SDN网络中通常采用反应式流安装，控制器的响应时间直接影响着流安装的处理速度，本文将重点测试在负载不同的情况下控制器处理packet_in消息的吞吐量和响应时间。同时也关注控制器支持创建openflow连接的能力与拓扑更新的速度。

4 测试环境硬件配置

备注：性能测试是对OpenFlow设备性能进行测试。由于目前测试整个网络系统还有很大的挑战，所以这里的性能测试指的是单个网络设备的性能。
Openflow版本：1.0
Ofchannel：tcp

5 测试执行

5.1 验证控制器支交换机上线的最大规模

5.1.1 测试目的

验证控制器所能接入交换机的最大数量。

5.1.2 测试拓扑

5.1.3 测试步骤

1)根据测试仪配置步骤，先添加port, 然后在Protocol中勾选openflow协议，如下截图：

2)Protocol Interface tab页中点击Add Mutiple Interface 按钮，批量添加多个interface（模拟多少个switch就添加多少个interface）

3)添加好端口后如下图所示

4)Openflow tab项中修改number of Devices

5)Devices中勾选Enable选项，修改Device Role为switch

6)Interface中勾选Enable选项，选择protocol Interface，修改number of switches及tcpport

7)Switches tab页中勾选Enable选项，修改Datapath Id

8)Switch of Channels tab页中勾选Enable 选项，修改Remote IP

9)Switch ports tab项中勾选enable选项，修改Number of ports 及Ethernet Address

10)按照以上步骤，配置好之后，点击启动协议即可。

5.1.4 测试结果及截图

1)测试仪上模拟1000个交换机
测试仪器上配置1000个交换机，配置switch of Channels,每个switch默认为1个ofchannel。配置截图如下：

修改tcp port.floodlight 默认端口为6653，然后启动switch,查看ofchannel建立的时延与数量

根据时间查看1000个交换机上线时延，从ofchannel通道建立开始到1000个建立完成，用时20s。

2)测试仪上模拟1200个交换机
测试仪器上配置1200个交换机，配置switch of Channels,每个switch默认为1个ofchannel。配置截图如下：

修改tcp port.floodlight 默认端口为6653，然后启动switch,查看ofchannel建立的时延与数量：

根据时间查看1023个交换机上线时延，从ofchannel通道建立开始到1023个建立完成，用时20s。

通过floodlight web界面查看，交换机的数量展示与上线通道数一直，均为1023。

模拟1200个交换机，与floodlight建立openflow连接，只有1023个openflow通道建立成功，交换机正常上线。测试多次，均为1023.所以单个floodlight控制器，最大支持1023个交换机同时上线。

5.1.5 测试结论

Floodlight V1.0控制器，在此次测试环境下，最大支持1023个交换机同时在线。

5.2 验证控制器支持的交换机上线的最佳数量

5.2.1 测试目的

验证控制器在正常的工作情况下可接入的交换机数量。

5.2.2 测试拓扑

5.2.3测试条件

设置交换机上线，可接受时延为6s。

5.2.4测试步骤

测试步骤按照测试仪模拟switch向导操作即可，此处不再赘述。

5.2.5 测试结果及截图

1)hub拓扑
测试仪模拟128个hub拓扑的交换机，建立与floodlight之间的openflow连接，查看ofchannel启动时延情况 6s。

测试仪模拟192个hub拓扑的交换机，建立与floodlight之间的openflow连接，查看ofchannel启动时延情况 6s。

测试仪模拟256个hub拓扑的交换机，建立与floodlight之间的openflow连接，查看ofchannel启动时延情况 8s。

测试仪模拟512个hub拓扑的交换机，建立与floodlight之间的openflow连接，查看ofchannel启动时延情况 18s。

2)full-mesh拓扑
测试仪模拟32个full-mesh拓扑的交换机，建立与floodlight之间的openflow连接，查看ofchannel启动时延情况 4s。

测试仪模拟48个full-mesh拓扑的交换机，建立与floodlight之间的openflow连接，查看ofchannel启动时延情况 6s。

测试仪模拟54个full-mesh拓扑的交换机，建立与floodlight之间的openflow连接，查看ofchannel启动时延情况 10s。

测试仪模拟64个full-mesh拓扑的交换机，建立与floodlight之间的openflow连接，查看ofchannel启动时延情况 12s。

测试仪模拟128个full-mesh拓扑的交换机，建立与floodlight之间的openflow连接，查看ofchannel启动时延情况60左右。

5.2.6 测试结果对比

5.2.7 测试结论

以上测试结果表明，正常使用场景下，控制器与交换机之间ofchannel建立的时延取决于交换机数量及交换机之间的link。当交换机以full-mesh拓扑结构互连，当交换机与控制器之间建立ofchannel通道时，会同时发送feature request消息获取交换机的特性等，导致交换机时延长。

5.3 验证控制器流表下发的速度

5.3.1测试目的

验证控制器下发流表的速度（每秒下发多少个流表）。

5.3.2 测试拓扑

5.3.3 测试步骤

1)按照测试仪switch配置向导，模拟2个交换机。
2)修改switch-packet_in tab项中的number of packetIn Ranges,如下截图：

3)switch PacketIn Ranges tab项中点击 PacketIn Headers配置packet_in报文。

4)填写in port，并配置测试packet_in（触发flow_mod的）报文如下截图，其中Destination Mac，与Source MacAddress 为switch下挂host的mac地址，500000为发包个数。

5)勾选中Send packetIn选项

6)启动openflow协议

7)openflow协议启动，ofchannel 状态为up后，勾选switch PacketIn Ranges tab项中的 Enable项发送packet_in报文。

8)测试过程中可以通过floodlight 的web界面，检查流表安装是否正确。

9)通过修改switch tab项中的number of Buffers与PacketIn Burst Size,确定发包速率。

5.3.4 测试结果及截图

备注：配置的packet_in报文，一条报文触发2条flow_mod消息，所以正常的应该flow_mod数量为packet_in数量的2倍。
1)配置number of Buffers 10000,PacketIn Burst Size 10000，2个交换机各发flow 500000次的情况下，测试3次，测试截图与结果见下图：

2)配置number of Buffers 50000,PacketIn Burst Size 50000，2个交换机各发flow 500000次的情况下，测试3次，测试截图与结果见下图：

3)配置number of Buffers 80000,PacketIn Burst Size 80000，2个交换机各发flow 500000次的情况下，测试3次，测试截图与结果见下图：

4)配置number of Buffers 90000,PacketIn Burst Size 90000，2个交换机各发flow 500000次的情况下，测试3次，测试截图与结果见下图：

5)配置number of Buffers 100000,PacketIn Burst Size 100000，2个交换机各发flow 500000次的情况下，测试3次，测试截图与结果见下图：

5.3.5 测试结果对比

根据上面测试结果，求不同速率下3次测试的平均值，对比如下图：

5.3.6 测试结论

在此次测试环境下，floodlight下发flow_mod的最大速率为33214个/s。

5.3.7 大压力的情况下测试

当 burst size在最大情况下，继续增大num buffers 为1000000时，floodlight 服务器上cpu占用率瞬间升高，最高瞬时可高达 635%, 但是下发flow_mod的速率明显小于发包速率。

备注：
(1)测试过程中floodlight控制器上的cpu ,mem均在正常负载下。
(2)测试floodlight建立ofchannel通道的能力时，编者怀疑测试结果受到了TCP连接数的限制，但是查找网上的方法，修改了之后，ulimit -n 查看为10240的情况下，测试结果仍然没有改变。