我的一个朋友,RedHat的Daniel Farrel,给我发了一个URL 题。 Daniel领导了OPNFV CPerf项目多年: https://wiki.opnfv.org/display/cperf CPerf是与来自成员的跨项目合作 ODL集成/测试,OPNFV和IETF基准测试方法 工作小组。我们通过测试工作学到了很多东西 和每周讨论(欢迎您加入我们当然)。
我阅读了你引用的会议论文,并分享了许多你的论文 关注。您的许多兴趣和问题都是针对性的, 我将分享一些链接并添加一些简短的答案 这可能有所帮助。
我也很惊讶作者排除了由于的ODL结果 性能低下。 ODL有很多测试结果, 包括CI测试结果: https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Performance_Test:Results 其中一项有趣的比较研究是由 几年前CPerf的成员: https://www.linux.com/news/sdn-developers-report-key-lessons-testing-opendaylight-performance
其中一个惊喜是持久性数据存储(这是一个 ODL的有价值的可靠性功能,默认启用) 是性能障碍,其他控制器没有提供此功能 功能或默认情况下未启用它。持久性数据存储区 必须在ODL中禁用以进行公平比较。好处 还评估了使用SSD进行数据存储的问题。 这里描述了最近对ODL控制器的测试: https://www.opendaylight.org/blog/2017/10/24/how-performance-testing-improved-the-nitrogen-release
另一个讨论主题围绕着“正确”的集合 控制器基准测试的指标。捕获CPerf项目的想法 在这张JIRA票中: https://jira.opnfv.org/projects/CPERF/issues/CPERF-3?filter=allopenissues 我们都同意的一点是OpenFlow Packet-IN丢失了 Flow-MOD响应是基准测试的关键指标。换一种说法, 许多控制器吞吐量测试也测量响应延迟 同时,和许多延迟很高的吞吐量 回答可能不代表有用的操作条件。 当Packet-INs没有响应时,情况也是如此, 并且CPerf同意吞吐量测量应报告 没有回复丢失的级别。我们的一位团队成员写了一篇 在控制器上部署为探针的golang工具: https://github.com/anastop/latte 并在OF接口上进行丢失和延迟测量。
我还提到了IETF基准测试方法WG 致力于控制器基准测试的规范和主要作者 这些互联网草案也参与了CPerf: https://tools.ietf.org/html/draft-ietf-bmwg-sdn-controller-benchmark-term-06 https://tools.ietf.org/html/draft-ietf-bmwg-sdn-controller-benchmark-meth-06
我希望你会发现这些材料对你的研究很有帮助。
人