OpenFlow のアーキテクチャは非効率であり、不必要な電力を消費しながらパフォーマンスを制限します。
これは、オーストラリアの頭脳集団Data61とシドニー大学のコンピュータサイエンスの研究者たちが、4つの主要なOpenFlowコントローラー（NOX、Maestro、Floodlight、Beacon）を評価した結論です。彼らの論文はArxivに掲載されています。
古き良き OpenDaylight もテストされましたが、報告されていません。「パフォーマンスが低すぎて、洞察に富んだ比較を行うことができませんでした。」
端的に言うと、テストしたコントローラは、ネットワーク プロセッサ (Tilera チップ ベース) 上で実行されていても、Xeon E5-2450 ベースのサーバー (構成については後述) 上で実行されていても、どれも回線速度に近づくことはありませんでした。
CBench ソフトウェア定義ネットワーク (SDN) コントローラー ベンチマークでは、Tilera セットアップが達成した最高値は 1 秒あたり 500 万リクエスト弱で、ライン レートは 1 秒あたり 2,900 万リクエストでした。
パケット処理を理解するための Intel の長年の取り組みが成果を上げているようです。x86 セットアップでは、Beacon は 1 秒あたり 2,000 万リクエストを達成できました。他のコントローラーの最大値は 1 秒あたり 700 万リクエストでした。
ラインレート？もう忘れよう：CSIRO/Data61/シドニー大学のベンチマーク結果
SDN コントローラはトラフィックをフローとして処理する必要があるため (つまり、トラフィックを転送するポートだけを知っていればよいイーサネット スイッチと比較して、会話を追跡するために MAC アドレスを記憶する必要がある)、ネットワークのスケーラビリティも大きな問題となります。
ベンチマークでは、1,000 万の固有 MAC アドレスでどのコントローラもピーク パフォーマンスに近い状態を維持できず、Java ベースのコントローラ (Beacon および Floodlight) はその規模でほぼ完全に停止してしまいます。
論文によると、問題はOpenFlow自体のアーキテクチャ上の非効率性にある。著者らは、シリアル化、I/Oスレッド、そして「学習スイッチアプリケーションの主要なデータ構造であるハッシュテーブル」を指摘している。
シリアル化は圧倒的に最大のオーバーヘッドです。最も効率的なコントローラーでさえ、「処理時間の5分の1をパケットのシリアル化に費やしています…この制限は、これらのコントローラーのオブジェクト指向設計原則に内在するものです。コントローラーはすべて、個々のパケットを個別のオブジェクトとして扱います。この制限により、パケットごとに許容できないオーバーヘッドが発生します。」
著者らは、新しいSDNコントローラ設計を提案している。「到着したパケットを新しいオブジェクトではなく、事前に割り当てられたバッファで処理する」と彼らは述べている。また、コントローラは「ハードウェア特性を考慮してマルチコアプラットフォームでのキャッシュミスを制限し、メニーコアプラットフォームではネットワークオンチップを活用する」必要がある。®
