[BMT] EOSIO TPS 테스트 2번째 결과 by EOSeoul - 블록원 테스트 가이드 검증과 JIT 사용 테스트

4월 24일 EOSeoul 리포트 TPS와 4월 26일 블록원 실험실 테스트

EOSeoul은 4월 24일 블록원에 EOSeoul의 BMT TPS 결과와 질의를 보냈습니다.

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

이어서 블록원은 메일 회신과 스팀잇, 텔레그램을 통해 블록원이 TPS 데이터를 얻은 테스트 방법을 공유했습니다.

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

블록원의 테스트 방식은 1개의 물리적인 시스템 위에서 1개의 블록 프로듀싱 노드와 1개의 풀 노드 사이의 binaryen 인터프리터를 이용하는 테스트 방식입니다. 간단하게 설명하면 블록원의 TPS 테스트 방식은 이오스의 순수한 엔진 성능만을 테스트하는 “실험실 테스트”입니다. 블록원의 테스트 세팅은 실제 서비스 환경에서 발생할 수 있는 다양한 성능 저하 요인을 제외하고, 오직 P2P를 통해 트랜잭션을 수신하고 이것을 블록으로 만들고 블록을 브로드캐스트하는 일련의 핵심 기능만을 TPS 수치로 환산합니다. 따라서 블록원의 테스트 방식은 자동차로 따지면 공인 연비 측정 방식에 가깝습니다.

EOSeoul의 TPS 테스트 방식은 위의 블록원의 실험실 TPS 테스트 방식과 방향이 다릅니다. EOSeoul은 메인넷 런칭 시뮬레이션의 전초전으로, 현재 거의 모든 BP 출마자들이 테스트넷으로 사용하는 클라우드 환경과 이오스 설정으로 진행했습니다. 현재 대부분의 BP 노드에는 HTTP plugin이 활성화되어 있고, 이를 통해서 트랜잭션을 받아들입니다. EOSeoul의 테스트 방식은 이와 같은 설정으로 테스트를 진행했습니다. 거기에 이오스 시스템이 망가질 수 있는 한계를 확인할 수 있도록 충분한 쿼리를 보냈습니다. 즉, 실제 서비스 환경에서 발생할 수 있는 성능 저하까지 어느 정도 포함하는 “스트레스 벤치마크”입니다. EOSeoul의 보고서는 메인넷 실제 운용에 초점을 맞춘 벤치마크이기 때문에 실험실 테스트에 비해 낮은 결과를 얻을 수밖에 없습니다. 따라서 EOSeoul의 테스트 방식은 자동차로 따지면 실연비 측정 방식에 가깝습니다.

블록원 테스트 검증과 재연

EOSeoul은 블록원의 실험실 테스트 방식으로 인텔 i7-6700 3.4GHz CPU 환경에서 1200+ TPS의 처리량을 확인했습니다. 또한 같은 CPU 환경에서 JIT을 활성화한 경우 2000+ TPS의 처리량을 확인했습니다. 이제 클라우드 환경에서 블록원과 동일한 방식으로 테스트를 하면 어떤 결과를 보여주는지 살펴보겠습니다.

클라우드 환경에서 블록원 테스트 방식 검증

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 확인 가능함. 다만, 일정 시간이 지나면 트랜잭션 처리량이 밀리는 느낌으로 보임. 불안정한 느낌. 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 : 1000 TPS 안정적으로 처리 가능. BP node CPU 30% , Full node 60% 정도 사용
• 20x22 : 1100 TPS 안정적으로 처리 가능. BP node CPU 36%, Full node 70% 정도 사용
• 20x24 : 1200 TPS 꽤 안정적인 상태로 보이나, 약간의 지연 느낌이 있음. BP node CPU 38%, Full node 78~80%
• 20x26 : 1300 TPS 안정적으로 보임 오히려 1200 TPS때보다 나은 느낌. BP node 42%, Full node 82~84%
• 20x28 : 1400 TPS가 나와야 하지만 실제로는 1000 TPS 정도 처리량 보여줌. CPU 사용량도 들쭉날쭉함.

벤치마크4. C5 EC2 3대 : FN2 + PN1

• 20x20 : 1000 TPS 안정적으로 처리 가능. BP node 33~38% , Full node1 58~64%, Full node2 52~56%
• 20x22 : 1100 TPS 안정적으로 처리 가능. BP node 38~40%, Full node1 68~72%, Full node2 58~64%
• 20x24 : 1200 TPS 안정적으로 처리 가능. BP node 40~42%, Full node1 74~80%, Full node2 60~70%
• 20x26 : 1300 TPS 정상적인 처리량 안 나오고 약 1000~1100 TPS 정도 성능, BP, Full node 모두 CPU 사용량이 들쭉날쭉함. Block 처리량이 밀리는건지 순간적인 처리량은 966까지 나오지만 그 다음 Block은 99정도로 낮음. 낮은 처리량일 땐 CPU 사용량이 당연히 낮아짐
• 20x28 : 1400 TPS 처리 불가. 에러로 인한 BMT중지.
• 20x12x2 : 600+600 TPS 안정적인 처리가 가능. 2개의 노드에서 같이 600 TPS 정도씩 발생한 것이라 Broadcast 시간때문인지 네트워크 전달 시간 때문인지 약간씩 밀리는 성향은 있으나, 안정적으로 처리함. BP node : 40~44%, Full node1 : 68~74%, Full node2 : 76~80%, Full node2의 CPU가 조금 더 높게 올라감.
• 20x14x2 : 700+700 TPS 순간적으로는 1400이 나오지만, 2개 node중 하나에서 에러로 인해 BMT가 종료됨. CPU 할당이 불가능하기에 에러가 발생하여 테스트가 종료된 것으로 보임. BP node 58~64%, Full node : 최대 98% 이상, 에러로 인해 테스트가 종료되었기 때문에 CPU 사용량은 의미가 없음.
• 20x20+20x6 : 1000 + 300 TPS 테스트에서도 불안정한 모습을 보이고 300 TPS에 해당하는 TEST Job이 곧 중단됨. CPU 사용량은 앞의 경우와 같음.

클라우드 환경에서 JIT을 활성화하고 블록원 테스트 방식 검증

벤치마크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를 함께 사용한다면 더욱 이상적인 성능을 기대할 수 있음.

감사의 말씀

EOSeoul은 EOSIO 벤치마크 테스트 보고서를 공유한 후 많은 분들로부터 뜨거운 피드백을 받았습니다. 피드백을 주신 모든 분들께 감사드립니다.

먼저 Daniel Larimer와 블록원 개발자분들께 감사드립니다. 혹시 4월 24일에 드린 벤치마크 보고서가 여러분의 기분을 상하게 만들었다면 사과드립니다. EOSeoul의 의도는 평균적인 서비스 환경에서 동작하는 EOSIO의 성능을 확인하는 것이었습니다. txn_test_gen plugin의 구성은 스트레스 테스트의 관점에서 다소 간단하다고 생각했고, 블록원은 더욱 복잡한 벤치마크 시나리오로 4월 6일 Dawn 3.0 출시 문서의 성능 결과를 얻었다고 가정했습니다. 여러분들의 노고로 EOSIO는 빛과 같은 속도로 발전하고 있는 것을 매일 github 로그를 통해서 확인하고 있습니다. EOSeoul의 문의에 친절하고 전문적인 모습으로 대응해주신 점에 대해 감사드립니다.

EOS Cannon을 비롯해서 다양한 피드백을 준 EOS BP 출마자들과 많은 관심을 가진 개발자들에게 감사드립니다. 여러분의 다양한 비평은 EOSeoul이 보다 객관적이고 신뢰할 수 있는 테스트를 할 수 있는 데 큰 도움이 될 것입니다. 특히 EOS Cannon은 블록원 실험실 테스트를 진행했고 그 결과를 EOSeoul에게 공유했습니다. 협력의 정신을 보여준 EOS Cannon에게 크게 감사드립니다. 앞으로 서로의 결과를 공유하며 보다 안정적인 메인넷 런칭에 집중하겠습니다.

스트레스 벤치마크 스크립트 제작과 결과 공유를 제안합니다

EOS 커뮤니티는 각 블록 프로듀서들이 제공하는 노드가 얼만큼의 성능을 보여주는지를 동일한 방식으로 측정한 자료를 원합니다. EOSeoul은 스트레스 벤치마크 스크립트를 github를 통해 공개했습니다.

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

이 스크립트를 이용하면 각 블록 프로듀서는 저마다의 성능을 측정할 수 있습니다. 블록 프로듀서 출마자들은 성능을 확인할 수 있는 스크립트를 커뮤니티에 제안하고, 실제 메인넷에 대응하는 확인 가능한 성능 보고서를 커뮤니티에 배포해주기를 권합니다. EOSeoul은 성능 측정의 표준을 마련하고 이를 통해서 보다 신뢰할 수 있는 메인넷 운영에 기여할 것입니다.

이 모든 내용에 대한 피드백을 언제나 환영합니다. 주저하지 마시고 EOSeoul에게 의견을 주세요. 아래 텔레그램 그룹에 가입하시면 EOSeoul의 최신 뉴스와 EOS와 관련된 기술적인 토의를 나누실 수 있습니다.

Telegram (English) : http://t.me/eoseoul_en
Telegram (简体中文) : http://t.me/eoseoul_cn
Telegram (日本語) : http://t.me/eoseoul_jp
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