#cbench

trio on the bench, what will they do

we're cutting it fuckin close with this one

redraw i did of a piece from 2021!! its rlly cool seeing how my style and designs of the sillies has evolved since then :,) also fall totally isnt almost over and i totally didnt put off finishing this until literally the last minute

(og version and versions w other bgs for if ur having a hard time seeing on ur theme under the cut)

Ria, he/her, 20+, this is a side blog and my main is ria-air

前回 OpenFlow コントローラのベンチマークを取るツールとして CBench について書いた。 せっかくなので、主要な OpenFlow コントローラのベンチマークを取ってスループットを比較してみることにする。 ベンチマークを取ったコントローラは以下の通り。

Ryu 3.3 (CPython 2.7.4) Ryu 3.3 (PyPy 2.1) Trema 0.4.4 (Ruby 1.9.3p194) Floodlight 0.90 (OpenJDK 1.7.0_25)

ベンチマークを取るには VirtualBox の VM を使った。 CBench を動かす VM とコントローラを動かす VM は分けて、両者の通信は VirtualBox の private network を経由して行う。 CBench を動かす VM

OS: CentOS 6.4 CPU: 2 Core RAM: 1024 MB

OpenFlow コントローラを動かす VM

OS: Ubuntu 13.04 LTS CPU: 2 Core RAM: 1024 MB

環境の概略図は以下のような感じ。

今回は CBench をスループットモードで使用する。 スループットモードでは CBench がエミュレーションする OpenFlow スイッチが規定回数分の PacketIn メッセージを送れるだけコントローラに送信する。 OpenFlow コントローラ (側のアプリケーション) では、その PacketIn に対して FlowMod メッセージを返信する。 CBench は返ってきた FlodMod メッセージの数を、処理できたメッセージの数としてカウントする。 使用するパラメータはひとまずメッセージ数 10000, テスト回数 10, スイッチ数 16, MAC アドレス 1000 にした。 上記の数値は Floodlight がプロジェクトで計測に使っているものみたい。 CBench のインストールは前回の記事で扱ったので省略する。 さあ、始めよう。

Ryu 3.3 (CPython 2.7.4)

まずは、前回も測定した Ryu を CPython 2.7.4 で動かしたものから測る。この後 PyPy も使うので、まずは Python 仮想環境を作って、そこに Ryu 3.3 をインストールする。

$ sudo apt-get install git python-pip python-dev -y $ sudo pip install virtualenv virtualenvwrapper $ cat << EOF >> ~/.bashrc source \`which virtualenvwrapper.sh\` export WORKON_HOME=$HOME/.virtualenvs export PIP_RESPECT_VIRTUALENV=true EOF $ source ~/.bashrc $ mkvirtualenv cpython-ryu33 $ git clone https://github.com/osrg/ryu.git $ cd ryu $ git checkout -b ryu-v33 v3.3 $ python setup.py install

ベンチマークに使うプログラムは前回と同様。

$ cd $ cat << EOF > bench.py # -*- coding: utf-8 -*- from ryu.base import app_manager from ryu.ofproto import ofproto_v1_0 from ryu.controller.handler import set_ev_cls, MAIN_DISPATCHER from ryu.controller import ofp_event from ryu.lib import ofctl_v1_0 class SampleApp(app_manager.RyuApp): OFP_VERSIONS = [ ofproto_v1_0.OFP_VERSION ] @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) def packet_in_handler(self, ev): ofctl_v1_0.mod_flow_entry(ev.msg.datapath, {}, ofproto_v1_0.OFPFC_ADD) EOF $ ryu-manager bench.py loading app bench.py loading app ryu.controller.ofp_handler instantiating app bench.py instantiating app ryu.controller.ofp_handler

早速測定してみる。

$ cbench -c 192.168.33.10 -p 6633 -m 10000 -l 10 -s 16 -M 1000 -t cbench: controller benchmarking tool running in mode 'throughput' connecting to controller at 192.168.33.10:6633 faking 16 switches offset 1 :: 10 tests each; 10000 ms per test with 1000 unique source MACs per switch learning destination mac addresses before the test starting test with 0 ms delay after features_reply ignoring first 1 "warmup" and last 0 "cooldown" loops connection delay of 0ms per 1 switch(es) debugging info is off 17:06:59.437 16 switches: flows/sec: 7167 6934 7153 6520 6448 7027 6492 6879 6973 7366 5656 6580 7009 7987 7245 6777 total = 11.021274 per ms 17:07:09.543 16 switches: flows/sec: 7130 6502 7365 5994 7631 6972 6635 6618 7640 6898 7213 6685 6232 6415 6726 7424 total = 11.003446 per ms 17:07:19.646 16 switches: flows/sec: 6025 6387 6508 6128 6506 6795 7355 6465 6300 6027 7298 6519 6357 6352 6450 7594 total = 10.506549 per ms 17:07:29.749 16 switches: flows/sec: 7900 6920 7500 7507 6979 6582 6822 7055 7120 6996 6565 7030 7048 7176 5258 6737 total = 11.118873 per ms 17:07:39.851 16 switches: flows/sec: 6757 7422 7432 6297 6688 7137 7421 6645 5485 6664 6443 7605 6328 5789 6307 6549 total = 10.696872 per ms 17:07:49.955 16 switches: flows/sec: 7350 7079 6841 6067 6776 5415 7029 6558 6653 6269 6965 6342 6357 7162 7112 6551 total = 10.651570 per ms 17:08:00.060 16 switches: flows/sec: 6945 6094 6130 6280 6661 6935 6601 6249 6327 6181 6629 6557 7213 5767 5935 6736 total = 10.323958 per ms 17:08:10.164 16 switches: flows/sec: 6884 6549 7058 6566 6824 7491 6008 6364 7637 7887 6727 6078 6629 6781 6558 6564 total = 10.860437 per ms 17:08:20.268 16 switches: flows/sec: 7494 6912 7426 6868 6480 7494 6995 6591 5884 7049 6589 7346 7407 5737 6533 7145 total = 10.994381 per ms 17:08:30.370 16 switches: flows/sec: 6897 6861 6378 6488 6871 7321 7590 6558 7746 7732 7123 6063 7262 5881 7198 7095 total = 11.106243 per ms RESULT: 16 switches 9 tests min/max/avg/stdev = 10323.96/11118.87/10806.93/263.16 responses/s

この環境では約 10.8 krps (response/sec) という結果が得られた。

Ryu 3.3 (PyPy 2.1)

次に、同じ Ryu でも処理系を変えて PyPy を使ってみる。 PyPy は Pythonz を使ってインストールした。

$ curl -kL https://raw.github.com/saghul/pythonz/master/pythonz-install | bash $ cat << EOF >> ~/.bashrc [[ -s $HOME/.pythonz/etc/bashrc ]] && source $HOME/.pythonz/etc/bashrc EOF $ source ~/.bashrc $ pythonz install -t pypy 2.1 $ mkvirtualenv pypy-ryu33 -p ~/.pythonz/pythons/PyPy-2.1/bin/pypy $ cd ryu $ python setup.py install $ cd $ ryu-manager bench.py loading app bench.py loading app ryu.controller.ofp_handler instantiating app bench.py instantiating app ryu.controller.ofp_handler

測定してみよう。

$ cbench -c 192.168.33.10 -p 6633 -m 10000 -l 10 -s 16 -M 1000 -t cbench: controller benchmarking tool running in mode 'throughput' connecting to controller at 192.168.33.10:6633 faking 16 switches offset 1 :: 10 tests each; 10000 ms per test with 1000 unique source MACs per switch learning destination mac addresses before the test starting test with 0 ms delay after features_reply ignoring first 1 "warmup" and last 0 "cooldown" loops connection delay of 0ms per 1 switch(es) debugging info is off 17:14:46.264 16 switches: flows/sec: 24774 20230 18335 23432 18906 19430 20892 21670 21920 20120 17731 19885 21406 19648 19162 21032 total = 32.856107 per ms 17:14:56.531 16 switches: flows/sec: 24899 26852 27163 27341 28592 24077 24949 26862 32253 30010 26496 26635 27091 29654 26848 26517 total = 43.622247 per ms 17:15:06.636 16 switches: flows/sec: 24720 28441 23902 27605 29639 23458 26215 30100 28197 25481 31490 28756 29709 22853 30724 26562 total = 43.779911 per ms 17:15:16.740 16 switches: flows/sec: 26069 28050 28997 25959 26001 29578 27665 23492 27817 31968 28057 29914 26560 27384 29768 25931 total = 44.314122 per ms 17:15:26.843 16 switches: flows/sec: 28708 28942 26260 30397 31132 27741 28831 27009 29668 25523 28397 30064 25885 23888 32258 26732 total = 45.143356 per ms 17:15:37.187 16 switches: flows/sec: 30766 27548 28401 28752 27193 25280 31869 26232 23531 28114 25871 28096 29167 27229 28831 30300 total = 44.713497 per ms 17:15:47.291 16 switches: flows/sec: 24129 23080 30353 25622 25160 25554 25903 28107 25310 27763 26021 25756 26725 24770 25026 28330 total = 41.753935 per ms 17:15:57.393 16 switches: flows/sec: 29415 28803 28032 28673 28152 28152 28804 29814 27800 23184 28938 27890 29336 24736 27984 27111 total = 44.681006 per ms 17:16:07.496 16 switches: flows/sec: 27158 25135 24917 25969 24451 30353 25466 26478 23314 29118 30832 23576 25216 29655 27459 30512 total = 42.960522 per ms 17:16:17.599 16 switches: flows/sec: 26524 25385 28029 28944 28202 26664 28109 27238 29961 28250 27593 26732 28109 29518 26583 23958 total = 43.978862 per ms RESULT: 16 switches 9 tests min/max/avg/stdev = 41753.94/45143.36/43883.05/975.97 responses/s

速ッ！！約 43.8 krps という結果になった。実に CPython の 4 倍のスループットだ。

Trema 0.4.4 (Ruby 1.9.3p194)

次に Trema を試してみる。 Rubygems からインストールして Ruby binding のベンチマーク用プログラムを書いた。

$ sudo apt-get install -y gcc make ruby-dev libpcap-dev libsqlite3-dev rubygems libglib2.0-dev $ sudo gem install trema $ cat << EOF > bench.rb class BenchController < Controller def packet_in dpid, message send_flow_mod_add dpid end end EOF $ trema run bench.rb

測定してみる。

$ cbench -c 192.168.33.10 -p 6633 -m 10000 -l 10 -s 16 -M 1000 -t cbench: controller benchmarking tool running in mode 'throughput' connecting to controller at 192.168.33.10:6633 faking 16 switches offset 1 :: 10 tests each; 10000 ms per test with 1000 unique source MACs per switch learning destination mac addresses before the test starting test with 0 ms delay after features_reply ignoring first 1 "warmup" and last 0 "cooldown" loops connection delay of 0ms per 1 switch(es) debugging info is off13:31:57.115 16 switches: flows/sec: 3776 0 944 2832 7552 15104 7552 12272 13216 13216 12272 7552 5664 9440 10384 0 total = 12.177154 per ms 13:32:07.218 16 switches: flows/sec: 7552 7552 6609 7552 6608 8496 6608 8496 8496 8496 8496 8496 7552 8496 8496 8496 total = 12.648194 per ms 13:32:17.320 16 switches: flows/sec: 8496 7552 8496 8496 7552 8496 7692 7552 7552 7552 6608 7552 8496 6608 7552 8496 total = 12.474766 per ms 13:32:27.425 16 switches: flows/sec: 7552 7552 7552 6608 8496 7552 8496 7552 6608 7552 8496 8496 6608 8496 7552 6608 total = 12.177075 per ms 13:32:37.530 16 switches: flows/sec: 6608 8496 8496 8496 7552 8496 7552 8496 8496 8496 7552 7552 7552 7552 7552 8496 total = 12.740824 per ms 13:32:47.633 16 switches: flows/sec: 7552 7552 6608 7552 6608 6608 6608 7552 7552 7552 7552 7552 7552 7552 8496 7552 total = 11.798723 per ms controller msgbuf_read() = -1: msgbuf_read: Connection reset by peer ... exiting $

ウッ！何か変だ。 Trema を動かしている方のコンソールも見てみよう。

$ trema run bench.rb Failed to send ( service_name = switch.0x10, fd = 39, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0xa, fd = 14, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0x9, fd = 15, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0xb, fd = 19, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0xf, fd = 21, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0xc, fd = 25, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0xd, fd = 31, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0x3, fd = 37, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0xe, fd = 23, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0x4, fd = 35, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0x5, fd = 27, errno = Broken pipe [32] ). Failed to send ( service_name = switch.0x7, fd = 29, errno = Broken pipe [32] ). Could not write a message to send queue due to overflow ( service_name = switch.0xd, fd = 4294967295, length = 106 ). Send queue is already deleted or not created yet ( service_name = switch.0x1 ). Send queue is already deleted or not created yet ( service_name = switch.0x8 ).

うーん、ベンチマークの負荷に耐えられなかったのかな…。 結果、何度か再試行してみるものの完走できず。ただし、途中までの測定内容を見るに、推定で約 12 krps 程だろう。

Floodlight 0.90 (OpenJDK 1.7.0_25)

次は Floodlight を試してみる。 これは Java で書かれているから速そう。(先入観) Floodlight の場合はデフォルトで PacketIn に対して FlodMod を返すモジュールが組み込まれているようなので、そのまま起動するだけで良い。

$ sudo apt-get install -y openjdk-7-jdk ant $ wget http://floodlight-download.projectfloodlight.org/files/floodlight-source-0.90.tar.gz $ tar xvf floodlight-source-0.90.tar.gz $ cd floodlight-0.90 $ ant $ java -jar target/floodlight.jar

測定してみる。

$ cbench -c 192.168.33.10 -p 6633 -m 10000 -l 10 -s 16 -M 1000 -t cbench: controller benchmarking tool running in mode 'throughput' connecting to controller at 192.168.33.10:6633 faking 16 switches offset 1 :: 10 tests each; 10000 ms per test with 1000 unique source MACs per switch learning destination mac addresses before the test starting test with 0 ms delay after features_reply ignoring first 1 "warmup" and last 0 "cooldown" loops connection delay of 0ms per 1 switch(es) debugging info is off 14:03:40.394 16 switches: flows/sec: 1602 819 31 848 974 905 909 2299 1767 804 1301 1437 1 804 1868 5 total = 1.637397 per ms 14:03:50.501 16 switches: flows/sec: 15189 14890 15090 14390 14690 14586 14589 14390 15189 15189 14390 13891 15087 15189 14390 14290 total = 23.534366 per ms 14:04:00.605 16 switches: flows/sec: 15989 15988 15988 16787 15989 15788 15988 16588 16489 15988 16188 15989 16487 15988 16188 16588 total = 25.892295 per ms 14:04:10.707 16 switches: flows/sec: 16383 15985 16385 16485 16786 15889 16688 15984 15984 15985 15984 16287 16689 15985 15984 16784 total = 26.025165 per ms 14:04:20.808 16 switches: flows/sec: 16788 16488 15988 15988 16784 15984 16484 16384 16188 16787 16788 16784 16384 16187 16388 16088 total = 26.246982 per ms 14:04:30.914 16 switches: flows/sec: 16787 16788 16388 16788 16488 16988 15988 16787 16487 16788 15988 16388 15988 16788 16188 15989 total = 26.352523 per ms 14:04:41.021 16 switches: flows/sec: 16285 16788 15984 15984 15989 16488 16488 15989 16786 16784 16784 15989 16188 16484 15985 16583 total = 26.148499 per ms 14:04:51.131 16 switches: flows/sec: 15988 16384 16388 16088 16583 15985 15984 16584 15986 16787 16188 15984 16384 16387 16787 15989 total = 26.038539 per ms 14:05:01.235 16 switches: flows/sec: 15989 15989 15988 15988 15989 16387 15688 15989 16588 16189 15189 16288 15989 16788 15989 16787 total = 25.779804 per ms 14:05:11.341 16 switches: flows/sec: 16283 16787 16784 16084 16787 16788 16788 16288 15986 15984 16484 15988 15988 16584 16783 15985 total = 26.235938 per ms RESULT: 16 switches 9 tests min/max/avg/stdev = 23534.37/26352.52/25806.01/820.97 responses/s

結果は約 25.8 krps だ。

結果発表

ということで、最終的には以下の通り。

Ryu 3.3 (CPython 2.7.4): 約 10.8 krps Ryu 3.3 (PyPy 2.1): 約 43.8 krps Trema 0.4.4 (Ruby 1.9.3p194): 未完走 (参考値: 約 12 krps) Floodlight 0.90 (OpenJDK 1.7.0_25): 約 25.8 krps

OpenFlow コントローラのパフォーマンスを測るツールを探していたところ CBench というものを見つけた。 プロトコルこそ OpenFlow 1.0 にしか対応していないものの、使えそうな感じ。 今回は CentOS6.4 で CBench を使って Ryu のベンチマークを取ってみた。 まずは CBench をインストールする。

$ sudo yum install -y git automake autoconf libtool net-snmp-devel libpcap-devel libconfig-devel $ git clone git://gitosis.stanford.edu/oflops.git $ cd oflops $ git submodule init $ git submodule update $ git clone git://gitosis.stanford.edu/openflow.git $ cd openflow $ export OFP_SRC=`pwd` $ git checkout -b release/1.0.0 remotes/origin/release/1.0.0 $ cd ../netfpga-packet-generator-c-library/ $ ./autogen.sh $ ./configure $ make $ cd .. $ ./boot.sh $ ./configure --with-openflow-src-dir=${OFP_SRC} $ make $ sudo make install $ which cbench /usr/local/bin/cbench

次に、別のマシンに Ryu 3.3 をインストールする。

$ sudo yum -y install git python-setuptools python-devel $ sudo easy_install pip $ git clone https://github.com/osrg/ryu.git $ cd ryu $ git checkout -b v33 v3.3 $ sudo python setup.py install

ベンチマークに使う Ryu のアプリケーションを作成する。 CBench では PacketIn に対して返された FlowMod の数をカウントするため、アプリケーションでは PacketIn のハンドラで空の FlowMod を返すようにしている。

$ cat << EOF > bench.py # -*- coding: utf-8 -*- from ryu.base import app_manager from ryu.ofproto import ofproto_v1_0 from ryu.controller.handler import set_ev_cls, MAIN_DISPATCHER from ryu.controller import ofp_event from ryu.lib import ofctl_v1_0 class SampleApp(app_manager.RyuApp): OFP_VERSIONS = [ ofproto_v1_0.OFP_VERSION ] @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) def packet_in_handler(self, ev): ofctl_v1_0.mod_flow_entry(ev.msg.datapath, {}, ofproto_v1_0.OFPFC_ADD) EOF

OpenFlow が使うポート (TCP 6633) を空けて、アプリケーションを起動する。

$ sudo iptables -I INPUT -p tcp -m tcp --dport 6633 -j ACCEPT $ ryu-manager bench.py loading app bench.py loading app ryu.controller.ofp_handler instantiating app bench.py instantiating app ryu.controller.ofp_handler

CBench をインストールしたマシンに戻って Ryu をインストールしたマシンに対して CBench を実行する。

$ cbench -c 192.168.33.10 -p 6633 -m 10000 -l 10 -s 16 -M 1000 -t cbench: controller benchmarking tool running in mode 'throughput' connecting to controller at 192.168.33.10:6633 faking 16 switches offset 1 :: 10 tests each; 10000 ms per test with 1000 unique source MACs per switch learning destination mac addresses before the test starting test with 0 ms delay after features_reply ignoring first 1 "warmup" and last 0 "cooldown" loops connection delay of 0ms per 1 switch(es) debugging info is off 13:26:51.925 16 switches: flows/sec: 4684 4051 4292 4359 3997 4186 5034 5593 5918 4467 5302 4652 5692 4039 3967 4994 total = 7.516007 per ms 13:27:02.028 16 switches: flows/sec: 4678 4530 4684 3969 4500 3839 4935 5201 5187 4990 4414 4141 3866 4253 4930 4510 total = 7.262407 per ms 13:27:12.131 16 switches: flows/sec: 4696 5473 3998 4784 5034 3622 4654 4983 4591 4499 3832 4650 5401 4753 4247 4092 total = 7.330858 per ms 13:27:22.233 16 switches: flows/sec: 5093 4236 4913 5380 4206 5311 3859 5418 4373 3674 4594 4113 4607 4910 4615 4869 total = 7.416450 per ms 13:27:32.334 16 switches: flows/sec: 5196 4083 4526 5204 5734 4814 5254 4141 5472 5039 3924 4589 4499 4992 4209 4802 total = 7.647716 per ms 13:27:42.438 16 switches: flows/sec: 5036 5325 4734 4375 4084 3872 4275 4464 4255 3661 5124 4521 5098 4606 4832 4157 total = 7.241001 per ms 13:27:52.540 16 switches: flows/sec: 4807 4462 5259 4098 3938 4600 5030 3874 5409 5797 5282 4123 3628 4562 4224 4500 total = 7.359220 per ms 13:28:02.643 16 switches: flows/sec: 5076 6602 4914 4579 4549 5233 3873 3860 4454 5454 5167 4177 4232 6053 4798 5822 total = 7.882888 per ms 13:28:12.749 16 switches: flows/sec: 4556 4670 5649 5872 5456 5072 5831 4433 5053 5096 4475 5021 4286 4924 5289 5336 total = 8.097632 per ms 13:28:22.853 16 switches: flows/sec: 5189 5141 5919 4927 4641 4581 4905 5376 4485 4263 4649 5273 4777 5659 5034 4909 total = 7.972618 per ms RESULT: 16 switches 9 tests min/max/avg/stdev = 7241.00/8097.63/7578.98/311.23 responses/s