继上篇《SDN控制器测试专题五:Floodlight性能测试报告(上)》测试结果，补充待完善测试步骤及测试结果，下篇主要包括Floodlight控制器流表下发延时、支持的最大流表数量、拓扑更新能力及Mac地址学习能力等性能方面的测试。

5.4 验证控制器流表下发时延

5.4.1 测试目的

验证控制器下发流表的时延（下发所有流表所用的时间）。

5.4.2 测试拓扑

同5.3.2

5.4.3 测试步骤

同5.3.3

注意：由于延迟时间等待较久，可设置参数Inter PacketIn Burst Gap 50，减小发包间隔时间。

5.4.4 测试结果及截图

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.4.5 测试结果对比

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

5.4.6 测试结论

从上面数据可以看出，在number of Buffers 50000,PacketIn Burst Size 50000时少数流表安装已经失败了。在此次测试环境下，floodlight下发flow_mod的最少延迟时间为100 s。

5.5 验证控制器支持的最大流表数量

5.5.1测试目的

验证控制器支持的最大流表数量。

5.5.2测试拓扑

测试拓扑同上篇5.3.2。

5.5.3 测试步骤

测试步骤同上篇5.3.3，测试时以一定的速率发送packetIn报文，直至flow_mod的下发速率小于packetIn的发包速率即可。

5.5.4 测试结果及截图

备注：配置的packet_in报文，一条报文触发2条flow_mod消息，所以正常的应该flow_mod数量为packet_in数量的2倍。

1)配置number of Buffers 75000,PacketIn Burst Size 50000，2个交换机各发flow 1000000次的情况下，测试结果如下：

结果分析：

正常情况下，flow_mod数量为packet_in数量的2倍，看曲线图发现，flow_mod速率约为packet_in的2倍，但是flow_mod的数量却比packet_in数量的2倍要少15万，存在明显的丢包情况。

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

5.5.5 测试结论

在此次测试环境下，floodlight支持的flow_mod的最大流表数量为25629个/s。

5.6 验证控制器拓扑更新能力

5.6.1测试目的

验证控制器在大规模交换机上线情况下的拓扑更新能力。

5.6.2 测试拓扑

拓扑同5.3.2。

5.6.3 测试条件

设置Link/port down/up，可接受时延为6s。

5.6.4 测试步骤

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

5.6.5 测试结果及截图

1)hub拓扑

1、测试仪模拟64个hub拓扑的交换机，建立与floodlight之间的openflow连接，查看控制器topo是否正确，执行link/port down/up，在控制器log日志中查看控制器对此消息的处理时间（notification与LinkDiscoveryManager之间的时间）。测试了几组数据，link down平均处理时间<1s，link up平均处理时间4-5s。

2、测试仪模拟128个hub拓扑交换机，建立与floodlight之间的openflow连接，查看控制器topo是否正确，执行link/port down/up，在控制器log日志中查看控制器对此消息的处理时间（接收到notification与控制器发送LinkDiscoveryManager之间的时间）。测试了几组数据，link down平均处理时间<1s，link up平均处理时间5-6s

3、测试仪模拟256个hub拓扑的交换机，建立与floodlight之间的openflow连接，查看控制器topo是否正确，执行link/port down/up，在控制器log日志中查看控制器对此消息的处理时间（接收到notification与控制器发送LinkDiscoveryManager之间的时间）。测试了几组数据，link down平均处理时间<1s，link up平均处理时间8s

4、测试仪模拟512个hub拓扑的交换机，建立与floodlight之间的openflow连接，查看控制器topo是否正确，执行link/port down/up，在控制器log日志中查看控制器对此消息的处理时间（接收到notification与控制器发送LinkDiscoveryManager之间的时间）。测试了几组数据，link down平均处理时间<1s，link up平均处理时间9s

5、测试仪模拟1022个hub拓扑的交换机，建立与floodlight之间的openflow连接，查看控制器topo是否正确，执行link/port down/up，在控制器log日志中查看控制器对此消息的处理时间（接收到notification与控制器发送LinkDiscoveryManager之间的时间）。测试了几组数据，link down平均处理时间<1s，link up平均处理时间8s

2)full-mesh拓扑

1、测试仪模拟32个full-mesh拓扑的交换机，执行link/port down/up，在控制器log日志中查看控制器对此消息的处理时间（接收到notification与控制器发送LinkDiscoveryManager之间的时间）。测试了几组数据，link down平均处理时间<1s，link up平均处理时间4-5s

2、测试仪模拟64个full-mesh拓扑的交换机，执行link/port down/up，在控制器log日志中查看控制器对此消息的处理时间（接收到notification与控制器发送LinkDiscoveryManager之间的时间）。测试了几组数据，link down平均处理时间<1s，link up平均处理时间7s

3、测试仪模拟128个full-mesh拓扑的交换机，执行link/port down/up，在控制器log日志中查看控制器对此消息的处理时间（接收到notification与控制器发送LinkDiscoveryManager之间的时间）。测试了几组数据，link down平均处理时间<1s，link up平均处理时间6-7s

4、测试仪模拟256个full-mesh拓扑的交换机，执行link/port down/up，在控制器log日志中查看控制器对此消息的处理时间（接收到notification与控制器发送LinkDiscoveryManager之间的时间）。测试了几组数据，link down平均处理时间<1s，link up平均处理时间10s。

5.6.6 测试结果对比

5.6.7 测试结论

以上测试结果表明，正常使用场景下，交换机拓扑更新的时延取决于交换机数量及交换机之间的link。交换机port down，控制器处理时间很短（小于1s），当交换机以full-mesh拓扑结构全互连，交换机port up，因会关联其他交换机，导致交换机时延长。

5.7 验证控制器mac地址学习能力

5.7.1 测试目的

验证控制器mac地址的学习能力。

5.7.2 测试拓扑

5.7.3 测试步骤

1)按照测试仪switch配置向导，4个port各模拟2个交换机，各交换机下下挂不同数量的host。并安照5.3.3所述的测试步骤配置各交换机，配置packetIn报文，与5.3.3所不同的是，保证packetIn报文中所配置的host mac地址唯一，具体配置如下截图：

5.7.4 测试结果及截图

场景：4个port，每个port下模拟2个交换机，每个交换机下挂1024个host

1)配置number of Buffers 1024,PacketIn Burst Size 1024,Burst Gap 50ms情况下测试6次，共发8196个包测试截图与结果见下图：

2)配置number of Buffers 2048,PacketIn Burst Size 2048,Burst Gap 50ms的情况下测试6次，共发8196个包测试截图与结果见下图：

3)配置number of Buffers 4096,PacketIn Burst Size 4096,Burst Gap 50ms的情况下测试6次，共发8196个包测试截图与结果见下图：

备注：此3个测试，由于每个交换机发包个数为1024，burst Size为1024，即表示测试仪一次发送1024个packetIn报文。

4)配置number of Buffers 1024,PacketIn Burst Size1024,Burst Gap 50ms的情况下测试6次，共发16392个包测试截图与结果见下图：

备注：由于测试仪设置一次发包1024，现在一个交换机共发包个数为2048，两次发包burst Gap时间为50ms,所以同样的速率（对比1和4），发包总数增加，速度会减小。

5)配置number of Buffers 2048 PacketIn Burst Size2048 ,Burst Gap 50ms的情况下测试6次，共发16392个包测试截图与结果见下图：

6)配置number of Buffers 2048 PacketIn Burst Size 2048 ,Burst Gap 50ms的情况下测试6次，共发24558个包测试截图与结果见下图：

7)配置number of Buffers 4096 PacketIn Burst Size 4096 ,Burst Gap 50ms的情况下测试6次，共发24558个包测试截图与结果见下图：

5.7.5测试结果

模拟交换机下挂1024个host，配置不同数量的packetIn报文，保证配置的packetIn报文中host的mac地址唯一，控制器收到packetIn报文，并下发flow_mod的速率即可表示控制器mac地址的学习能力。

5.7.6 测试结论

从上面测试可知，在此次测试环境下，当mac地址唯一，控制器处理packetIn报文，学习到host的mac地址，并下发flow_mod的最大能力为10223个/s。

备注：测试过程中floodlight控制器上的cpu ,mem均在正常负载下。