パフォーマンス測定の条件・手順について【第4回】
目次
Introduction
調査結果紹介
2.1 Caliper を使った性能測定
2.2 Ethereum 性能評価に関して
2.3 経験に基づく検討観点共有
まとめ
参加者一覧
NTT テクノクロス株式会社
- 兼松 和広
株式会社日立ソリューションズ
- 吉田一省
株式会社コンプス情報技術研究社
- 西村 祥一
SingulaNet 株式会社
- 町 浩二
クーガー株式会社（主催）
石井 敦
石黒 一明
佐々木 俊平
田中 滋之
辰巳 ゆかり
清水 啓太
1. 議題
第４回では、ブロックチェーンのパフォーマンス測定をどのような前提条件や手法で進めるべきかを議論する。各社調査結果を共有することでディスカッションの材料とし、検討を進めた。
2. 調査結果紹介
2.1 Caliper を使った性能測定
NTT テクノクロス株式会社｜兼松和広
ファイルダウンロードはこちら
Hyper Caliper の使い方を紹介する。
主に下記を用いることで、負荷の調整、および複数台のノードに対しトランザクションを投げて測定結果をまとめてくれるのが、Caliper の機能である。
caliper を操作するための CLI ツール
負荷をかける本体
ベンチマーク用のサンプルアーティファクト
worker process に対して指示を与える機能
大まかな処理の流れは下記のとおり。
1.caliper manger を起動
a. docker-compose で環境構築
b. 負荷測定開始
c. 負荷測定終了
d. docker-compose で環境を解体
2.コマンドラインに結果が返る
3.html でレポートが作成される
2.2 Ethereum 性能評価に関して
株式会社日立ソリューションズ｜吉田一省
ファイルダウンロードはこちら
Ethereum の性能評価に関する調査結果を以下のとおり報告する。
測定ポイント
ブロックチェーンへのトランザクションリクエストから戻りを得るまでの時間。
測定種別は、台帳更新系と台帳参照系。
固定項目・変更項目
測定するスマートコントラクトは ERC20 などに固定化する必要がある。
初期発行量や測定メソッドなども決める必要あり。
Genesis.json…性能測定用に前提条件として固定値を決めておく必要あり。
ノード数…コンセンサスアリゴリズムにより最低必要なノード数で測定する。
ブートノード…Bootnode を配置した構成にするか、静的に配置するか決めておく必要あり。
測定項目
API の発行と戻り時間
一定期間でのトランザクション発行可能数
2.3 経験に基づく検討すべき観点の共有
株式会社コンプス情報技術研究社｜西村祥一
過去に Layer2 の負荷計測、パフォーマンス計測を実施した際に検知した、意見を伺いたい点や懸念点などを共有する
西村：キャリパーは web socket 経由でないと利用できず、制約があるのではないか。
吉田：利用できない。HL・Geth は web socket に対応できるが、その他対応出来ないチェーンの場合は測定が難しい。
西村：Layer2 などをテスト対象とする場合、1 台のマシンでかけられる負荷では不十分な可能性がある。その場合、キャリパーでのマルチワーカー対応が必要になるのではないか。
⇒ 上記の認識で関係者同意。
西村：限りなく低負荷な処理を行った場合の性能測定をどのように行うか。
町：コードログを仕掛けた。アプリログよりも詳細なレベルで出力できることが望ましい。
3. まとめ
各社の調査・過去事例の共有により、Caliper を利用したパフォーマンス測定の方法が明確になった。次回以降は本ワーキンググループの成果物としてのホワイトペーパー作成、ならびにテスト実施・結果の共有を進めていく。
また、テスト前提とするユースケースは、ネイティブトークンの送金ではなく、少なくともスマートコントラクトを使ったものとし、具体的には ERC20 を対象としたい。