DHCPの負荷テスト
DHCPの負荷テストツールで、手軽に使えて便利なものがなかなかありませんでした。高価なネットワーク試験装置にはDHCPの負荷テストもできるものがあったりしますが、それだけのために購入するのはあまりにも高価すぎ。フリーソフトでありそうなものと探しても意外とないもので、私の場合はProDHCPを開発しはじめた頃に負荷テストツールも自作したのでした。
しかし、自分の製品を自分のテストツールで測定しても、何となくインチキ臭い感じもすると思っていた頃、お客さんから「ノミナム社がフリーで公開している」という情報をいただき、以後、そのツールを使ってきました。
ノミナム社の負荷テストツールは良くできているのですが、気になる点もあります。
・RHEL5系の32bit用のバイナリのみの配布（ソースは公開されていない）
・オプションの終了マークがつかない
・リクエストのオプションなどの内容を指定できない
・リレーエージェント経由のシミュレーションができない
ソースが公開されていれば簡単に改良できそうな内容ばかりなのですが・・・
ということで、自分でもっと便利な負荷テストツールを作ろうと何度考えたことでしょう。実際いくつか作ったのですが、どちらかというと負荷テストツールというよりはデバッグ用ツールの色合いが濃いものばかりできてしまいました。「やっぱり普通に便利なものは、仕様を決めて他の人に依頼する方が確実（自分で作ると好きなところばかりこだわってまとまらないから）」ということで、今年早々にある人に依頼したのですが、あまり得意な分野でなかったらしく、惜しいところまでという状態。先日ようやく他の仕事から解放されつつあるメンバーのU君に依頼したところ、素晴らしいできばえのものが仕上がってきました！
せっかくなので、きちんとドキュメントも用意して公開する予定で準備を進めています。残念ながらソースの公開はしない予定ですが（してもビルド環境を整えるだけでも大変かも）、ノミナム社のツールに対する不満は満たされた状態のツールで、便利に使えると思います。
さて、せっかくなので、ProDHCP(Ver.11.8)とISC-DHCP(4.1.1-P1)を比較してみました。今回は仮想マシン環境で、DHCPサーバも負荷ツールも同じサーバ（他にもたくさんのVMが動いている）内の別VMという簡易的な条件での測定です。
まずは、/24セグメントで200万IPというそこそこの規模のdhcpd.confを準備しました。リレーエージェントのシミュレーションができるので、この中の1つのセグメントへの要求で負荷をかけて測定してみます。
% : lease / all : subnet : shared-network-name
====================================================================================
0% : 0 / 254 : 192.168.1.0 : noname-1
0% : 0 / 254 : 192.168.2.0 : noname-2
・・・
0% : 0 / 254 : 192.198.193.0 : noname-7873
0% : 0 / 4 : 192.198.194.0 : noname-7874
0% : 0 / 254 : 10.19.254.0 : TARGET-NETWORK
0% : 0 / 0 : 10.9.0.0 : local
Total 7876 subnets ================================================================
0% : 0 / 2000000 : ALL : ALL
測定結果は、
ProDHCP：Finished and report: 781 transactions per second.
ISC-DHCPD：Finished and report: 687 transactions per second.
と、ProDHCPの方が少し高速という感じです。
あまり大きな声では言えませんが、実は元の状態では同じかやや負けるくらいだったので、この機会に少し高速化したのでした。このツールはノミナム社のツールと同様に、自動で負荷を変化させながら限界性能を測定します。デフォルトでは2分間の失敗率が0.1%未満であれば成功と判断します。ProDHCPは様々な背景から（ここで書くと長いので説明は省略：下にある著書に詳しく書いてありますので・・・）マルチプロセスやマルチスレッドによる並列化を使っていません。リースタイムアウトチェック処理を定期的に割り込ませていたのですが、それが2分間安定して払い出し続けることを要求する測定とあまり相性が良くなかったので、そこらへんをチューニングしたのでした。もちろんマルチスレッドやマルチプロセスは使わずに・・・
もっとも、ProDHCPは払い出し性能が高いということが売りではなく、「起動・設定反映時間が高速」ということが重要でして、このdhcpd.confの状態でHUPシグナルを与えて設定反映（ほぼ再起動）を行うと、
Oct 22 17:10:47 komata-centos62-1 local7.notice: dhcpd: SigHupFunc:(1):Wed Oct 22 17:10:47 2014
Oct 22 17:11:07 komata-centos62-1 local7.notice: dhcpd: main:dhcpd ready ::: Wed Oct 22 17:11:07 2014
20秒
20秒で完了します。もう少し稼働環境がまともだともっと高速で、数秒です。
ISC-DHCPDでは設定反映するためにはプロセスの再起動が必要で、
Oct 22 17:31:25 komata-centos62-1 daemon.info: dhcpd: Internet Systems Consortium DHCP Server 4.1.1-P1
Oct 22 17:34:14 komata-centos62-1 local7.info: dhcpd: Sending on Socket/fallback/fallback-net
2分49秒
一度終了させた後に起動させましたが、かなりの時間がかかります。
実行サイズも、
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 5131 18.7 14.3 376700 294164 pts/1 S 16:51 3:33 ./dhcpd eth3:1 ←ProDHCP
root 5184 12.4 0.7 677540 14560 ? Ss 17:15 1:59 dhcpd -cf dhcpd.conf eth3:1 ←ISC
半分くらいです。
ついでに、同じ200万IPでも/16セグメントで構成したdhcpd.confで確認すると・・・
% : lease / all : subnet : shared-network-name
====================================================================================
0% : 0 / 65534 : 172.17.0.0 : noname-1
0% : 0 / 65534 : 172.18.0.0 : noname-2
・・・
0% : 0 / 65534 : 172.45.0.0 : noname-29
0% : 0 / 33980 : 172.46.0.0 : noname-30
0% : 0 / 65534 : 10.19.0.0 : TARGET-NETWORK
0% : 0 / 0 : 10.9.0.0 : local
Total 32 subnets ================================================================
0% : 0 / 2000000 : ALL : ALL
こんな設定です。
ProDHCP：Finished and report: 93 transactions per second.
ISC-DHCPD：Finished and report: 93 transactions per second.
同じくらいの結果で、同じ200万IPでもかなり払い出し性能が落ちてしまいます。ProDHCPでの遅くなる理由は、対象セグメントを検索する処理でのループがかなり増えてしまうためです。基本的には大きなセグメントは嫌われますので、小さなセグメントでの性能優先で作ってあります。
設定反映時間や実行サイズは/24のときと、どちらも同じくらいです。
今回の負荷測定ツールではオプションの指定などもかなり自由にできますので、オプション82を使った払い出し制御などにも対応した測定ができるようになります。
ツールを公開した際にはまたお知らせします！