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社内のハードウェア環境で十分と思われる。

懸念点