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 設計に関係ない最適化ポイントもまだあるので、並行してやっていきたいです。
