Feature

K2HFTFUSE のパフォーマンス測定結果について


目次

パフォーマンス測定結果

他プロダクトとの比較測定結果

まとめ

Appendix


パフォーマンス測定結果

パフォーマンス結果(ボトルネックとなる環境なし)

10 Gbps ネットワークと SSD を使用し、H/Wによるボトルネックが無い環境で転送量の計測を行いました。

測定した内容

3パターンのデータファイルを用意しました。

このファイルをクライアント3台からサーバー1台に送信してデータ転送量を計測します。

図3

使用した H/Wスペック

使用した環境

測定方法

データの投入方法

データの集約方法

パフォーマンス測定結果

図1

転送量は 最大で 250MB となりました。(4096 Byte レコード送信時)

レコード長 平均転送レコード数(秒) 平均転送バイト数(秒)
10 Byte 937,779 8.9 MB/S
1024 Byte 219,578 214.4 MB/S
4096 Byte 64,943 253.7 MB/S

1Gbps ネットワークでの測定(ネットワークのボトルネック環境)

上記と同様に転送量の計測を目的としたテストを 1Gbps ネットワークで行った際の結果です。
この結果はネットワーク性能が不足している場合の挙動になります。

テスト環境

テスト方法

転送量の計測は、10秒ごとに集約したファイルのライン数をカウントして計算値を出しました。
計測が終わるとファイルを削除して、作り直されたファイルに書き込んでいきます。

テスト結果

図7

転送量は 100MB 付近で最大となり、long サイズと middle サイズで差分があまり見られませんでした。

外部からモニタリングツールで確認した結果、 実際に回線速度の上限に達していることが確認できました。 よって、この計測ではネットワーク上限での挙動を見ることができていますが、本来の性能は計測できていません。

まとめ


HDD 使用環境での測定(ファイル・デバイスのボトルネック環境)

上記と同様に転送量の計測を目的としたテストを HDD で行った際の結果です。
この結果はファイル・デバイスの性能が不足している場合の挙動になります。

テスト環境

テスト方法

10秒ごとにファイルサイズをチェックして、10秒前のサイズとの差分から転送量を計算しました。

テスト結果

図11

転送量は 150MB 付近で最大となり、long サイズと middle サイズで差分があまり見られませんでした。
計測後にさらに転送を継続した際にパフォーマンスが急激に下がる現象が発生したので、転送完了までの推移を確認したのが下のグラフです。

図4

同時にモニタリングツールで見てみると、計測中にフリーメモリがキャッシュに割り当てられて徐々に減少し、枯渇したところで遅くなる事がわかりました。 このグラフの時は150秒付近で最高速が出なくなり、700秒付近ではフリーメモリがほぼ無くなった状態になっていました。

この計測では SSD ではなく HDD を使っているので、受信したデータを書き込む際にディスクの速度が追いつかず、最終的にメモリを使い果したと想像できます。 出力先を /dev/null にしてネットワーク帯域の使用状況を見てみると、転送完了まで途中で速度低下することなく推移したので HDD がボトルネックであると確認できました。

まとめ


他プロダクトとの比較測定結果

同じユースケースで他のプロダクトを使用してみるとどうなるか、 fluentd と kafka で比較してみました。

今回パフォーマンス測定をしたプロダクトとバージョンです。

データの投入方法

データの集約方法

パフォーマンス測定結果


10 Byte レコード
図11


1024 Byte レコード
図12

図13


まとめ

K2HFTFUSE の性能について

K2HFTFUSE の性能は、10Gbps のネットワークと高速なストレージを準備して初めて上限に達しました。 それ以下の環境で利用する際には、K2HFTFUSE の限界よりも先に、ネットワークやディスク書き込み速度が上限に達します。 よって、既存の大多数のシステム上で K2HFTFUSE の限界を気にせず有効に使うことができます。

K2HFTFUSE が効果的なユースケース

今回は、K2HFTFUSE の想定しているユースケースのひとつである、ログ転送を主目的としたパフォーマンスの調査をしました。 結果として、ログ転送において想定以上のパフォーマンスを確認できました。 この結果から、

などといったユースケースが効果的だと思います。

また、他のプロダクトと比較したときの、

という特長を活かせる場面も多いと思います。

おわりに

今回は比較対象として同じような機能を持っている fluentd と kafkaと比較してみましたが、私はこの2つのプロダクトのプロフェッショナルではありません。 そのため、これらのプロダクトについて精通している方がチューニングして計測した場合はもっと良い結果になると思います。 同じユースケースでチューニングした結果があればぜひとも公開していただければと思います。 また、他のユースケースでの計測結果があれば K2HFTFUSE でも検査をしてみたいと思います。


Appendix

今回の計測方法や、計測に使用した設定ファイルです。


測定方法の決め方について

測定方法に至るまでの準備や試行錯誤を簡単に紹介します。

インストール

弊社内の開発用サーバーとネットワークを手配して各プロダクトのインストールと、チュートリアルにある疎通確認までを行いました。
fluentd と kafka は高速化のためのチューンを特に行わずに使用しています。

予備テスト

データファイルとサーバー構成を変えながら計測しました。

この結果を参考にして専用環境でテストする際の計測方法やデータサイズをあらためて検討しました。


計測スクリプト

サーバ側で集約したファイルは以下のスクリプトを使って書き込みバイト数を計算しました。

#!/bin/bash
pre=0
while :
do
	date=`date`
	now=`ls -l log.txt | awk '{print $5;}'`
	num=`expr $now - $pre`

	echo -n "$date "
	echo $num

	pre=$now
	sleep 10
done

K2HFTFUSE 設定ファイル(受信側)

今回の測定で使用した設定ファイルです。

# k2hftfuse server side
#
# GLOBAL SECTION
#
[GLOBAL]
FILEVERSION			= 1
DATE				= Thu, 03 Sep 2015 17:27:28 +0900
GROUP				= K2HFUSETEST
MODE				= SERVER
DELIVERMODE			= random
MAXCHMPX			= 5
REPLICA				= 0
MAXMQSERVER			= 64
MAXMQCLIENT			= 64
MQPERATTACH			= 1
MAXQPERSERVERMQ			= 2
MAXQPERCLIENTMQ			= 32
MAXMQPERCLIENT			= 8
MAXHISTLOG			= 0
PORT				= 8020
CTLPORT				= 8021
SELFCTLPORT			= 8021
RWTIMEOUT			= 10000
RETRYCNT			= 1000
CONTIMEOUT			= 500000
MQRWTIMEOUT			= 20000
MQRETRYCNT			= 2000
MQACK				= no
DOMERGE				= on
AUTOMERGE			= on
MERGETIMEOUT			= 0
SOCKTHREADCNT			= 8
MQTHREADCNT			= 4
MAXSOCKPOOL			= 8
SOCKPOOLTIMEOUT			= 0
SSL				= no
K2HFULLMAP			= on
K2HMASKBIT			= 8
K2HCMASKBIT			= 7
K2HMAXELE			= 32
K2HPAGESIZE			= 5000

#
# SERVER NODES SECTION
#
[SVRNODE]
NAME				= xxxx.yahoo.co.jp
SSL				= no

#
# SLAVE NODES SECTION
#
[SLVNODE]
NAME				= [.]*
CTLPORT				= 8022

[K2HFTFUSESVR]
TYPE				= file
FILE_BASEDIR			= /tmp/k2hftfusesvr
FILE_TIMEFORM			= "%F %T.%-"
#FORMAT				= "%T +0900 temotest': {'message':'%l','host':'%H'}\n" # for JSON format
FORMAT				= "%L"
FILE_UNIFY			= log/unify.log

#
# VIM modelines
#
# vim:set ts=4 fenc=utf-8:
#

K2HFTFUSE 設定ファイル(送信側)

今回の測定で使用した設定ファイルです。

# k2hftfuse slave side
#
# GLOBAL SECTION
#
[GLOBAL]
FILEVERSION			= 1
DATE				= Thu, 03 Sep 2015 17:27:28 +0900
GROUP				= K2HFUSETEST
MODE				= SLAVE
DELIVERMODE			= random
MAXCHMPX			= 5
REPLICA				= 0
MAXMQSERVER			= 64
MAXMQCLIENT			= 32
MQPERATTACH			= 8
MAXQPERSERVERMQ			= 16
MAXQPERCLIENTMQ			= 1
MAXMQPERCLIENT			= 8
MAXHISTLOG			= 1000
PORT				= 8020
CTLPORT				= 8022
SELFCTLPORT			= 8022
RWTIMEOUT			= 100000
RETRYCNT			= 10000
MQRWTIMEOUT			= 50
MQRETRYCNT			= 20000
CONTIMEOUT			= 500000
MQACK				= no
DOMERGE				= on
AUTOMERGE			= on
MERGETIMEOUT			= 0
SOCKTHREADCNT			= 0
MQTHREADCNT			= 8
MAXSOCKPOOL			= 8
SOCKPOOLTIMEOUT			= 0
SSL				= no
K2HFULLMAP			= on
K2HMASKBIT			= 8
K2HCMASKBIT			= 4
K2HMAXELE			= 32

#
# SERVER NODES SECTION
#
[SVRNODE]
NAME				= xxxx.yahoo.co.jp
PORT				= 8020
CTLPORT				= 8021
SSL				= no

#
# SLAVE NODES SECTION
#
[SLVNODE]
NAME				= [.]*
CTLPORT				= 8022

#
# K2HTPDTOR
#
[K2HTPDTOR]
K2HTPDTOR_BROADCAST		= no
K2HTPDTOR_FILTER_TYPE		= DELKEY

[K2HFTFUSE]
K2HTYPE				= mem
K2HMASKBIT			= 8
K2HCMASKBIT			= 4
K2HMAXELE			= 32
K2HPAGESIZE			= 4096
DTORTHREADCNT			= 2
BINTRANS			= no
TRANSLINECNT			= 10000
TRANSTIMEUP			= 10
BYTELIMIT			= 0

#
# K2HFTFUSE_RULE_DIR( K2HFTFUSE sub rule )
#

[K2HFTFUSE_RULE_DIR]
TARGET          = senddir
TRUNS           = on
DEFAULTALL      = ALLOW

#
# VIM modelines
#
# vim:set ts=4 fenc=utf-8:
#
Feature