仮想化のキャパシティプランニングでそのサーバが実際どれくらい転送能力があるのかを測定する必要が出てきました。
(NICやスイッチは1Gbpsなんですが、実測は違いますからね。。)
ということで使ってみたツールが Jperfというものもです。(ほんとに費用掛けて評価するならSmartBitsとかIXIAとかを使うこともできるんですが。。)
(上記リンク先からダウンロードできるのはソースのみです。IperfのWindowsバイナリは Jperf の bin フォルダ内にありました。Linuxで使いたいときは #./configure → #make → #make install ってする必要があります。参考元:ネットワークのスループット測定Linux編（nuttcp、Iperfのインストール）)
Javaで書かれてるのでJREが必要ですが、Linuxとかでも動くのはうれしいですね。
ダウンロードは Google Code か 本家のページからできます。
(Linuxで Jperf 動かすには上記にあるように Iperf のソースをコンパイルしてパスを通しておく必要があります。CentOSで既定の設定でビルドすると /usr/local/bin/iperf が作成されます。ここはパスが通っているようです)
デフォルトだと TCP のパケットサイズは 8KB なので適宜サーバの用途に合わせて調整は必要かもしれません。
(ファイルサーバとかだともっと大きい値を指定しないといけないでしょうしね。)
結果がグラフででるのも好感です。
いくつか測定してみたのでスクリーンショット載せてみます。
↓100MbpsのLANでデフォルトの設定で測定したものです。(TCPパケットサイズ8KB)平均49Mbpsです。時間経つうちにスループットが落ちてます。
↓100MbpnのLANでTCPパケットサイズを1MByteで測定したものです。平均83Mbps出てますね。
↓OpenVPNを使ってインターネットVPN拠点との速度を測定したものです。設定値はデフォルトです。平均1.1Mbpsです。パケットサイズが小さいとオーバヘッドが大きいのでスループットは落ちますね。
↓OpenVPNでTCPパケットサイズを1Mbpsにしたものです。平均7.7Mbpsです。やはり安定してますね。
↓Linuxでサーバとして動かしたときのイメージです。
参考:
補足というか修正
上記で、Jperf の Buffer Length という項目(Iperfだと-lオプション)が、テストを行う ｢TCPのパケットサイズ｣ というように説明してましたが、これは間違いのようです。
正しくは、read、writeするときのバッファ長のことのようです。（デフォルトはTCP：8KB、UDP：1470B）
なので、あまり気にする項目ではなさそうです。このバッファにデータが溜まったら、Jperfに通知するというのものみたいですね。余りに大きい値にするとバッファに溜まるまではJperfに通知しないので、結果が乱高下した感じになります。
(ただ｢10GbE で性能出そうと思ったら、これだと小さすぎるので、-l 64kとか128kにするとよいかも｣ということが、ここに書かれてました。)
重要なのは TCP window size サイズですね。WindowsとかだとRWINと呼ばれており、一時期ブロードバンド回線ならこの値を大きくすることでネットの高速化につながるというような情報もちらほら見られました。
(ウィンドウサイズというのはTCPにおいて、送信側のパケットに対して受信側が毎回のACK(受信確認)を返すと効率が悪いので、送信側が複数のパケットを送信し、その複数パケットに対してまとめて1回のACKを返すというウィンドウ制御で、どれくらいのパケットが来たらACKを返すかというサイズです。詳しくは@IT:基礎から学ぶWindowsネットワーク 1．信頼性のある通信を実現するための仕組みやRWINを調節する意義や、ウィンドウとは -- Key：雑学事典が参考になります。)
参考追加：
