LXCF ソース (lxcf-0.11.tar.gz) | 2014-11-14 12:01 |
LXCF DEB パッケージ (lxcf_0.11_amd64.deb) | 2014-11-14 11:52 |
LXCF RPM パッケージ (lxcf-0.11-1.x86_64.rpm ) | 2014-11-14 11:58 |
specfiles (lxcf.spec-0.11-1) | 2014-11-14 12:03 |
LXCFによって作成したLXCコンテナの性能を測定します。
LXCFでは、ホスト上で動作するアプリをそのまま実行できるLXCコンテナ環境を作成できます。
ここでは、JavaとMariaDBを使ったベンチマークを実行しましょう。
なぜ、LXCFの性能ではなく、LXCの性能なのでしょうか?
LXCFは、いろいろなアプリケーションをHOST上と同様に実行できるLXCコンテナを作成するツールだからです。
LXCのコンテナではすばらしい性能を発揮しますが、その上に環境構築するのが現状では結構大変です。
そこでLXCFを使うとそのような高性能なLXCの環境構築が極めて簡単かつ短時間でインスタントに生成できてしまいます。
データベース負荷テストツールJdbcRunner(http://hp.vector.co.jp/authors/VA052413/jdbcrunner/)でDBの銀行窓口業務モデルであるTPC-Bを使い、実機(Bare metal)、LXC、KVMの3者の上で性能を評価します。
TPC-B とは、 TPC によって策定されたベンチマーク仕様の一つです。銀行の窓口業務をモデルにしたトランザクションを実行し、システムの性能を測定します。
KVMでは、個別の環境においてデータベースを配置して、DBのサービスを起動することは実績もあり問題ありません。LXCコンテナにおいては同様にデータベースのような複雑なシステムの配置が可能かどうか多少不安がありました。しかし、実際には、DBサービスを導入することによりなんら問題なくベンチマーク・テストを実行できることを確認できました。
スループット時間についてグラフにします。
スループットの結果より、LXCはBare metalに近い値を示し効率が良いことが分かります。
Bare metalと比べた場合のオーバーヘッドを見てみると、KVMは34.9%ほどのオーバーヘッドが存在します。しかし、LXCのオーバーヘッドはより小さな4.3%のオーバーヘッドにすぎません。
圧倒的にLXCはオーバーヘッドが少ないといえるでしょう。
次にLatency time(レスポンス)時間についてグラフにします。
Bare metal(実マシン)とLXCでは、Latency のピークはどちらも7msに集中します。しかし、KVMでは30msにピークがあり、また集中せずになだらかに分散してしまっています。 つまり、LXCのLatencyはBare metalと同じくらいよく、また応答までの時間もほぼ安定して集中することがわかりました。LXCは実マシンと同等の反応を示すことをあらわします。KVMでは、レスポンスが遅れてしかもばらつきが多いです。普通に操作してもVMは全体的にもっさりとした操作の印象を受けるのはこのような特性に原因があります。LXCはそのようなことなく、実マシンの操作と同様な反応速度を示します。
これらのことより、TPC-Bモデルでは、LXCはオーバーヘッドも極めて少なく、またLatencyも低いため、ほぼ実機と同じ性能特性を示します。KVMと比べてもLXCは性能面から見れば優位な仮想環境を構築できるといえます。
[PageInfo]
LastUpdate: 2014-04-18 22:47:06, ModifiedBy: niwa-hideyuki
[Permissions]
view:all, edit:members, delete/config:members