[BMT]第2回目EOSIO TPSテスト結果by EOSeoul - BlockOneのテストガイド検証とJITテスト

4月24日EOSeoulレポートTPSと、4月26日BlockOne実験室テスト

EOSeoulは4月24日、BlockOneにEOSeoulのBMT TPS結果と質疑を送りました。

• https://steemit.com/en/@eoseoul/bmt-eosio-tps-results-by-eoseoul

続いて、BlockOneはメール返信と共に、スティーミットおよびテレグラムにてBlockOneがTPSデータを得たテスト方法について共有しました。

• Instructions : https://gist.github.com/spoonincode/fca5658326837b76fd744d39b2a25b4e
• github issue : https://github.com/EOSIO/eos/issues/2078
  

BlockOneのテストは、1つの物理的システムの上、1つのブロックプロデューシングノードと1つのフルノードの間のbinaryenインタープリターを利用するテスト方式になります。
簡単に説明致しますと、BlockOneのTPSテスト方式は、EOSの純エンジン性能のみをテストする「実験室テスト」です。BlockOneのテストセッティングは、実サービス環境で起こりうる様々な性能低下要因を除外し、P2P間のトランザクションを受信、これらをブロック化、そのブロックをブロードキャストするという、一連の核心機能のみをTPS数値に換算します。従って、BlockOneのテスト方式を車に例えますと、公認燃費測定に近いとも言えます。

EOSeoulのTPSテスト方式は、上記BlockOneの実験室TPSテスト方式とは方向性が異なります。EOSeoulは、メインネットローンチシミュレーションの前哨戦に当たり、現在、ほぼ全員のBP立候補者たちが、テストネットで使用するクラウド環境およびEOS設定で進行を行いました。現在、殆どのBPノードにはHTTP pluginが活性化されていて、こちらにてトランザクションを受け取ります。EOSeoulのテスト方式はこのような設定で実施しました。そして、EOSシステムが壊れてしまう限界を確認すべく、十分なクエリーを送りました。即ち、実サービス環境での発生が予想されるある程度の性能低下までを含む「ストレスベンチ・マーク」を実施しました。EOSeoulの報告書は、メインネットの本番運用にフォーカスしたベンチ・マークになりますため、実験室テストに比べ低い結果を得る他ありませんでした。従って、EOSeoulのテスト方式は、車に例えますと、実燃費測定方式になります。

BlockOne テスト検証と再演

EOSeoulは、BlockOneの実験室テスト方式で、intel i7-6700 3.4GHz CPU 環境での 1200+ TPSの処理を確認致しました。又、同様の CPU 環境で JITを活性化させた場合、2000+ TPSの処理を確認致しました。では、クラウド環境でBlockOne同様の方式でテストを行うと、どんな結果を見せるかご覧ください。

クラウド環境での BlockOne テスト方式検証

Test 環境情報

• Build : DAWN-v3.0.0 (d9ad8eec)
• AWS EC2 m5.2xlarge
  • CPU : Intel Xeon Platinum 8175M 2.5Ghz * 8 Core
  • Mem : 32G
  • Disk : EBS 120GB SSD (3000 IOPS Fix)
• AWS EC2 C5.2xlarge
  • CPU : Intel Xeon Platinum 8124M 3.0Ghz * 8 Core
  • Mem : 16G
  • Disk : EBS 120GB SSD (3000 IOPS Fix)

テスト説明

• txn_test_gen 設定
  • 発生周期(ms) x トランザクション数(count per interval)
  • 20x20 : 20ms ごとに 20 トランザクション 生成
  • 50x60 : 50ms ごとに 60 トランザクション 生成

ベンチ・マーク1. M5.2xlarge - EC2 1 : FN 1 + PN 1

• 20x20 (1000TPS) : 1000 TPS 確認可能。ただし、一定の時間が経過すると Transaction 処理量に遅れ気味。不安定。BP node CPU : 42%、Full node CPU : 82%
• 22x20 (約 900TPS) : 比較的安定。BP node : 35%、Full node : 78% 程度。
• 50x60 (1200TPS) : 処理中に CPU 100% となって中断される。処理不可。
• 60X58 (966TPS) : 途中から処理が不安定化。ただし処理量そのものは 966 TPS と確認される。BP node : 40%、Full node : 79%

ベンチ・マーク2. C5.2xlarge - EC2 1 : FN 1 + PN 1

• 20x20 : 1000 TPS 安定処理が可能。BP node CPU 30%、Full node 65% 程度使用。
• 20x22 : 1100 TPS 安定処理が可能。BP node CPU 34~35%、Full node 75% 程度使用。
• 20x24 : 1200 TPS かなり安定した状態。BP node CPU 38%、Full node 80% 程度使用。
• 20x26 : 1300 TPS 処理量出ず。約 1000 TPS 程度のみ処理できるレベルまで落ちる。BP Ndoe CPU : 43%、Full node : 83%
• 50x60 : 1200 TPS 上記同様
• 50x66 : 1320 TPS が理想的だが、正常な TPS 結果とならず。

ベンチ・マーク3. C5 EC2 2台 : FN1 + PN1

• 20x20 : 1000TPS 安定処理可能。BP node CPU 30% 、Full node 60% 程度使用。
• 20x22 : 1100TPS 安定処理可能。BP node CPU 36%、Full node 70% 程度使用。
• 20x24 : 1200TPS 安定状態に見えるが、少々遅れ気味。BP node CPU 38%、Full node 78~80%
• 20x26 : 1300TPS 安定的。1200 TPSより良い調子。BP node 42%、Full node 82~84%
• 20x28 : 1400TPS 程が理想だが、実際は 1000 TPS 程の処理量を見せる。CPU 使用量も一定せず。

ベンチ・マーク4. C5 EC2 3台 : FN2 + PN1

• 20x20 : 1000TPS 安定処理可能。BP node 33~38% 、Full node1 58~64%、Full node2 52~56%
• 20x22 : 1100TPS 安定処理可能。BP node 38~40%、Full node1 68~72%、Full node2 58~64%
• 20x24 : 1200TPS 安定処理可能。BP node 40~42%、Full node1 74~80%、Full node2 60~70%
• 20x26 : 1300TPS 処理量が正常でなく、約 1000~1100 TPS程度の性能、BP、Full node 全件 CPU 使用量が一定しない。Block 処理量に遅れがあるのか、瞬間処理量は 966まで現れるが、次の Blockは 99程度と低い。低い処理量の際は、CPU使用量が当然低くなる。
• 20x28 : 1400 TPS 処理不可。エラーによる BMT中止。
• 20x12x2 : 600+600 TPS 安定処理可能。2つのノードで両方 600TPS 位発生、Broadcast 時間またはネットワーク伝達時間の影響なのか、少々遅れ気味はあるが安定的に処理。BP node : 40~44%、Full node1 : 68~74%、Full node2 : 76~80%、Full node2の CPUが少々高く上がる。
• 20x14x2 : 700+700TPS 瞬間 1400まで出るが、2つのノードのうち片方のエラーにより BMTが終了。CPU 割り当ては不可能であるため、エラーが発生しテストが終了した様子。BP node 58~64%、Full node : 最大 98% 以上、エラーによりテストが終了したため、CPU使用量は無意味。
• 20x20+20x6 : 1000 + 300 TPS テストでも不安定な様子であり、300 TPSに該当するTEST Jobが時期に中止される。CPU使用量は上記と同様。

クラウド環境にてJITを活性化し、BlockOneテスト方式を検証

ベンチ・マーク5. C5 EC2 2台 : FN1 + PN1 (Using WAVM ~ JIT)

• 20x20(1000 TPS) : 非常に無難。CPU使用量もBP node 30~34%、Full node 33~37% 程度。
• 20x30(1500 TPS) : 非常に無難。1500 TPS を確認。BP node 50%、Full node 55% 程度。
• 20x36(1800 TPS) : 安定した 1800 TPS を確認。BP node 56~60%、Full node 66~70% 程度。
• 20x38(1900 TPS) : 安定した 1900 TPS を確認。BP node 58~62%、Full node 68~72% 程度。
• 20x40(2000 TPS) : 開始と同時に失敗。処理限界量の超過が原因とみられる。CPU Clock より高いサーバーにてテストを行うか、最適化が必要になると思われる。

結果考察

• Dawn 3.0 文書にて Dan Larimerが話した 1000 TPS(Worst case)は確認可能。しかし、この結果はエンジンに対する性能テストであり、様々は変数のある実サービス環境では、性能と異なる挙動があることが予想される。
• ベンチ・マーク1と2の結果により、メインネット初期に関しては、CPU性能の優れたサーバーを使用することが理想的と確認。
• Full nodeを BP node サーバーと分離した結果、多少の性能向上はあり。間違いなく Full nodeと BP nodeを分離すべき。ただし、性能にそれほど大きな影響があるとは考えられない。
• メインネット構成のストレステストは、BP nodeとFull nodeを別途置いてテストを進行することが望ましい。BP nodeが Full node の役割まで果たしている現在の TESTNET アーキテクチァーは、性能を含む様々な面から、不適切なアーキテクチァーと判断される。
• Full node の増加による性能低下を確認。1300 TPS を基準に、Full node 1つ BP node 1つ構成では安定した結果を得たが、Full node 2つ BP node 1つ構成では、実際に測定された TPSが 1300以下を記録するなど、不安定な結果となる。
• BP ノードの増加の際も、性能低下が予想される。BP node間の通信によって発生するリソース占有が、全体システムの性能を落とすことが考えれる。
• これらは、BP nodeと Full nodeが処理した Block およびトランザクションを、他ノードに Broadcastすることで発生した性能低下と思われる。従って、ノード個数が多いほど性能低下が予想される。
• JITを活性化する場合、性能の向上を期待できる。Dawn 3.0 文書での宣言同様、初めて配布されるコントラクトには binaryenを使用し、バックグラウンドで JITを合わせて使用すれば、より理想的な性能を期待できる。

御礼

EOSIOベンチ・マークテスト報告書を共有して以来、EOSeoulは、多くの方々から熱意溢れるフィードバックを頂きました。フィードバックを送って頂いた全ての方に、深く感謝致します。

先ずは、Daniel LarimerとBlockOne関係者の皆様に心から感謝します。4月24日付でお送りしたベンチ・マーク報告書がみなさんの気を害してしまったのなら、この場をお借りしてお詫び申し上げます。
EOSeoulの意図は、平均的なサービス環境にて問題なく動作するEOSIO性能を確認することでした。txn_test_gen pluginの構成は、ストレステストの観点で簡単であると考えましたため、BlockOneはより複雑なベンチ・マークシナリオにて4月6日 Dawn 3.0 文書の性能結果を得たと仮定しました。皆様のおかげで、EOSIOの著しい発展を日々githubログにて確認させて頂いております。EOSeoulのお問い合わせに新設かつ丁寧にご対応いただき、誠にありがとうございます。

EOS Cannonを含む、熱い想いで様々なフィードバックを下さったEOS BP立候補者の皆様と開発者の皆様に感謝致します。皆様のフィードバックは、EOSeoulがより客観的で信頼できるテストを実施するに当たって大いに役立つことでしょう。特にEOS Cannonは、BlockOne実験室テストを進行し、その結果をEOSeoulに共有させて頂きました。協力頂いたEOS Cannonに深く感謝致します。この先も両社の結果を共有し、より安定したメインネットローンチに尽力します。

ストレスベンチ・マークスクリプト製作と、その結果共有を提案致します。

EOSコミュニティーは、各ブロックのプロデューサーたちが提供するノードがどれ位の性能を示しているか、同方式で測定した資料を求めます。EOSeoulは、ストレスベンチ・マークスクリプトをgithubにて公開致しました。

• https://github.com/eoseoul/scripts/tree/master/bmt_client

こちらのスクリプトを利用することで、各ブロックのプロデューサーはそれぞれの性能を測定することができます。私たち以外のBP立候補者は、性能を確認できるスクリプトをコミュニティーに提案、実際にメインネットに対応する確認可能な性能報告書をコミュニティーのほうに配布して頂きたく思っております。EOSeoulは性能測定の標準を用意し、それにてより信頼できるメインネットの運営に貢献することでしょう。

すべての内容に対するフィードバックは、いつでも歓迎致します。遠慮なく、EOSeoulまでご意見およびご要望ください。以下のテレグラムグループに加入頂きますと、EOSeoulの最新ニュースとEOS関連の技術的ディスカッションを行うことができます。

Telegram (日本語) : http://t.me/eoseoul_jp
Telegram (English) : http://t.me/eoseoul_en
Telegram (简体中文) : http://t.me/eoseoul_cn
Telegram (General Talk, 한국어) : https://t.me/eoseoul
Telegram (Developer Talk, 한국어) : https://t.me/eoseoul_testnet
Steemit : https://steemit.com/@eoseoul
Github : https://github.com/eoseoul
Twitter : https://twitter.com/eoseoul_kor
Facebook : https://www.facebook.com/EOSeoul.kr