おくみん公式ブログ

おくみん公式ブログ

Influent ベンチマーク - Part 3 #fluentd

f:id:okumin:20170124002659p:plain

Java 製 Fluentd サーバ、Influent のベンチマーク第三弾です。

今回は Influent マルチスレッド化の成果と、Fluentd 0.14 で導入されたマルチプロセスワーカーの性能を計測しました。

テスト概要

http://blog.okumin.com/entry/2017/01/24/002953#テスト概要

Disclaimer

http://blog.okumin.com/entry/2017/01/24/002953#Disclaimer

テスト環境

マシンスペック

送信側には Google Compute Engine asia-northeast1 リージョンの n1-highcpu-32 を、受信側には n1-highcpu-64 用いました(注: 2017/5/31現在、日本語ドキュメントには n1-highcpu-64 についての記載がないようです)。

送信側は上記スペックのインスタンスを15台用意し、それぞれ20プロセス、合計300プロセスの Fluentd が並列にイベントを送信します。

バージョン

環境構築は influent-benchmark の 43ef11b491b2eec65efd24324ef3037533f69ade で行いました。

Influent は 568f89de61190a445122fc3fc6c26bfc5839f56fを、Fluentd サーバはバージョン 0.14.16を、Fluentd クライアントはバージョン 0.12.35 を用いました。

プロトコル

Fluentd 0.12 を用いて、at-most-once(require_ack_response なし)プロトコルでイベントを送信しました。

送信クライアントに Fluentd 0.14 を用いなかった理由は以下です。

  • Fluentd 0.14 で新しく追加された機能のほとんどが Influent に実装されていない
  • Fluentd 0.14 の in_forward で Fluentd 0.14 の out_forward を受けるとなぜか性能が低下した
    • 多分パラメータかなにかが好ましくないんだと思います
    • 今回関心のある箇所じゃないので原因は調べてません

今回の改善ポイント

イベントループのスレッド数を調整できるよう改良しました。
単一のスレッドで動作させると CPU がボトルネックとなるため、並列度を増やすことで解決を狙います。

Fluentd 0.14 では奇しくも同じような機能を提供するマルチプロセスワーカーが導入されたので、ついでにそれと比較してみました。
Fluentd v0.14.12 has been released | Fluentd

テスト結果

Fluentd の場合はワーカープロセス数を、Influent の場合はイベントループスレッド数を増減させて、それぞれの並列度に対する最大スループットを記録しました。
いずれも並列度を増やすと、秒間1600万イベントまでは線形にスループットが向上しました。
またプロセス数、スレッド数に応じてより多くの CPU が使用されていることもわかります。
秒間1600万イベント(15〜16Gbps)で頭打ちになるのはネットワーク帯域を使い切ったのだと予想してますが、GCP のドキュメントにはインバウンド上限の記載が見当たらず、確かなことは分かってません。

Fluentd Influent
並列数 受信イベント数(秒間) CPU(%) 受信イベント数(秒間) CPU(%)
1 800,000 100 2,000,000 120
2 1,500,000 200 4,000,000 250
4 2,550,000 400 8,000,000 440
8 5,150,000 800 15,500,000 850
16 10,000,000 1600 16,000,000 950
32 16,000,000 2800 16,000,000 1000

雑感

Influent に関しては大体予想通りの結果でした。

Fluentd のマルチプロセスワーカー機能も完璧に CPU を使えていて、若干立つ瀬がなくなってきた感じがあります。
マルチプロセスワーカーが使えると運用が容易になるので、td-agent 3 にはとても期待してます。

次やりたいこと

API 再設計

前回の記事に対し frsyuki 先生にコメントいただき、イベントのデータ構造から見直そうと思い始めました

性能最適化

今回みたいに API 設計に関係ない最適化ポイントもまだあるので、並行してやっていきたいです。

関連リンク