Jubatus 0.4.0 RPC性能評価 作業案(1)

gistfile1.md

Jubatus 0.4.0 RPC性能評価(1)

概要

Jubatus 0.4 のリリースにともなって RPC実装が pficommon ベースから mpio/msgpack-rpc ベースに移行した。これによって RPC性能がどのように 変化したか傾向を確認する

ゴール

• 0.3.x と比較して、0.4.0 のRPCパフォーマンスが改善していること（もしくは 低下していないことを）確認する
• まずは大まかな傾向を確認する
• もしなにか問題があれば、原因および改善方法を検討する

測定項目

必須測定項目：

• スループット
• レイテンシ

以下の項目も可能であれば測定する：

• CPU負荷（ server, keeper ）
• メモリ使用量（ server, keeper ）

測定方式

測定方式（共通）

• Jubatus 0.3.4 vs 0.4.0
• client, keeper は同一マシン、server は別マシンで実行する
• keeper, server としては recommender を用いる。ただし、mix を無効化する （ mix無効化は、mix 開始契機パラメータ（学習回数、間隔）に十分大きな値を 設定することで実現）
• RPC性能測定は、recommender complete_row_from_id メソッドの実行について行う
• スループットは、用意したデータすべての問い合わせが完了するまでの時間を測定し、#query/sec を算出
• レイテンシは、各問い合わせ毎の所要時間を測定し、平均と分散を算出する （ただし、様子をみて最大最小5%分程度のサンプルは破棄するかも）
• 学習および問い合わせデータは人工データ使用
• client は C++ で記述する

測定1: 分散なしの場合

• 環境 PC1=client, PC2=server

• バリエーション

  • client: #process=1, #thread=[ 1, 2, 4, 8 ]
  • server: #process=1, #thread=[ 2, 4, 8 ]

  ※ 様子をみて組み合わせパターン削減あり

測定2: 分散ありの場合

• 環境 PC1=[ client, zk ], PC2=server

• バリエーション

  • client: #process=1, #thread=[1, 2, 4, 8 ]
  • keeper: #process=1, #thread=(use default)
  • server: #process=[ 2, 4, 8 ], #thread=(use default)

  ※ 様子をみて組み合わせパターン削減あり ( 0.3系での keeper のボトルネックが 顕在化しそうな client#thread=8, server#process=2 だけ測定、など )

測定環境

まずは傾向が確認できればよいと考えているので、ONICOS社内のハードウェア環境で十分と思われる。

懸念点

Jubatus本体のアルゴリズムなどは分離し、RPCサーバ・クライアントのみの性能評価を個別に用意した方がよいかもしれない。

正直 そこは迷ったところでして…。 read/write lock 実装改善などは影響しそうですね。 アルゴリズムを分離したサーバを用意するようにします。

また、RPCのサーバとクライアントがあるが、pficommonとjubatus/msgpack-rpcのそれぞれにおいてサーバ、クライアント単体でどちらの性能が優れるか評価できると理想である。

なるほど。たぶん libevent と mpio ( = epoll + thread-pool ) どっちが速いかという勝負になるような気がしますが、様子をみて別途準備したいと思います。