はじめに
この記事ではデータベース(以下DB)サイズがJMeterのテスト（トークン移転の負荷テスト）中にどれだけ増加するかをまとめました。
Jmeterを実行する際に考えられるシナリオは以下の4点となります。
- Corda Nodeを起動したときのDBサイズ(トランザクションなし)
- 700アカウント作成時のDBサイズ
- 1つのFungible Tokenが700個のアカウントそれぞれから発行されたときのDBサイズ
- 1つのFungible Tokenが700個の各アカウントから100秒間で10回移動(計7,000回のトークンの移転、70TPS)されたときのDBサイズ
1．Corda Nodeが起動したときのDBサイズ
下の表はCorda Nodeをデプロイして起動した直後のDBサイズの内訳です。このタイミングではTransactionは発行されていません。
２．700件のアカウント作成時のCorda Node DBサイズ
700件のアカウント作成時のCorda Node DBサイズの内訳は以下のようになりました。
このデータと「１．Corda Nodeが起動したときのDBサイズ」を比較してみます。
以下の項目において目立った増加をしていることがわかります。
- vault_states
- vault_linear_states
- state_party
- accounts
大まかにいうと、アカウントが作成されたときに、１アカウントあたり約2kBほどの(全DBサイズに対して)メモリを要することを示しています。
3．700件のFungible Tokenが発行されたときのDBサイズ
700件のFungible Tokenが発行されたときのDBサイズの内訳は以下のようになりました。
このデータと「2．700アカウント作成時のCorda Node DBサイズ」を比較したものが以下になります。
以下の項目において目立った増加をしていることがわかります。
- vault_states:
- vault_fungible_states
- state_party(約1kB / Account)
- pk_hash_to_ext_id_map (約1kB / Account)
- fungible_tokens(約1kB / Fungible Token)
メモ
- 大まかに、1つのFungible Tokenを作成するのに1アカウントあたり約7 kB(全DBサイズに対して)必要ということを意味します。
- 表の
pk_hash_to_ext_id_mapはCordapp内のアカウントがどのように管理されているかによって変わります。
4．7000のFungible Tokenを移転させたときのDBサイズ
7000のFungible Tokenを移転させたときのDBサイズは以下になります。
これを「３．700のFungible Tokenが発行されたときのDBサイズ」と比較したものが以下になります。
以下の項目において目立った増加をしていることがわかります。
- vault_states
- vault_fungible_states
- state_party
- pk_hash_to_ext_id_map
- fungible_token (1kB / Fungible Token)
メモ
- DBサイズは7000のトークンを移転させるのに42 MB増加しました。
- 大まかに、Fungible Tokenを1つのアカウントから別のアカウントに移動するのに必要なメモリは1アカウントあたり約6kB(全DBサイズに対して)となります。
fungible_Tokenの項目は新しいトークンが記録(例：トークンの発行または移動)されると1 kBの増加が確認できました。
結論
- 1つのFungible Tokenを発行するのに約7 kB使用します。
- 1アカウントを作成するのに約2kBを使用します。
- 7000のトークンを移転させると42MBのDBサイズの増加がみられました。なお、これはCordappの設計によっては値が増減しうることにご留意ください。
VAULT_STATES項目のDBサイズは急激に上昇するが、大きくなりすぎたときにDBAによってアーカイブされるかもしれません(参考資料)。- Stateの実際の内容は
NODE_TRANSACTIONS項目からバイナリ表現の逆シリアル化をすることで取得できます(参考資料)。そのためVAULT_STATES項目のDBサイズは実際には問題になりません。 NODE_TRANSACTIONS項目は非常に大きなDBサイズになりえます。この項目は増える一方であり、データは変更できず、DBマネージャーを利用してもアーカイブできません。