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++ で記述する
-
環境 PC1=client, PC2=server
-
バリエーション
- client: #process=1, #thread=[ 1, 2, 4, 8 ]
- server: #process=1, #thread=[ 2, 4, 8 ]
※ 様子をみて組み合わせパターン削減あり
-
環境 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サーバ・クライアントのみの性能評価を個別に用意した方がよいかもしれない。
Jubatus 0.3.xと0.4.0で、バグ修正や機能改善があった場合、RPCではなく別の部分がレイテンシとスループットに影響を与えてしまい、RPCの性能評価にならない可能性がある。例えば、read/write lockの実装改善などがある（バージョンアップで、総合的にパフォーマンスに優劣つけることはできそう）。
jubatus/jubatus@5a97d97#src/framework/server_helper.hpp
また、RPCのサーバとクライアントがあるが、pficommonとjubatus/msgpack-rpcのそれぞれにおいてサーバ、クライアント単体でどちらの性能が優れるか評価できると理想である。サーバについては、msgpack-rpc本体のサーバよりもJubatusで使用しているJubatus版のcommon/rpc_serverを使うとよりJubatus向けのRPC性能評価として適切かと思う。