Measure network latency in paust-db prototype accompanied by changes in block size

[kwjooo]

배경 block size가 높을 수록 한번의 consensus에 처리할 수 있는 tx의 양이 많아지지만 consensus에 걸리는 시간은 길어진다. block size별 실험을 통해 최적의 block size를 찾아보려한다.

목적 tendermint block size에 따른 latency 변화를 측정해 paust-db에 가장 적합한 block size를 구하려함

연구 계획 block size 변경을 통한 latency 측정

• tendermint 4 validator cluster docker bridge network를 이용해 구성

• data set block 크기를 가득 채우기 위해 client에서 대용량 데이터 전송(tx당 byte고정, block size를 다 채우기 위한 설정)

• block size 에러가 나지 않는 최소단위의 block size부터 시작하여 block size를 선형 혹은 2의 제곱으로 증가

• latency Node별 Block이 새로 쌓이는 데에 걸리는 시간(consensus에 걸리는 시간)의 평균을 통해 latency측정

예상되는 결과 block size별 block이 쌓이는 시간을 graph를 그려 후에 있을 block size 책정에 대한 자료로 삼으려 함.

[elon0823]

block 이 100메가 아래로 권장되는 것 같던데 50메가만 되도 tx 를 단순한 text 만으로 채우기엔 단일노드로 1000 tps 가 나와도 다 채우기 힘들것으로 예상됩니다. 용량이 좀 되는 이미지들을 base64 인코딩해서 tx 에 리얼로 담아서 보내던가 하면 좋을듯하네요. tx 크기에 대한 설정도 테스트 해보시면서 테스트 커멘트 남겨주세요

[kwjooo]

tx size를 바꾸어가며 실험해본 결과 real data에 549kb까지 담을 수 있고 tx 크기의 한계는 732kb입니다.

[kwjooo]

block size 설정 : config/genesis.json 파일에 consensus_params를 추가하여 block size변경 tx request : 최대 tx size인 732kb를 1초에 한번씩 request하도록 설정(0.5초간격, 0.7초 간격으로 실험하였을 시 mempool이 가득차서 실험불가) latency 측정 : tendermint의 pubsub feature를 통해 newBlock event 발생 시 time을 얻을 수 있고 이전 블록 time과 현재 block time의 차를 통해 latency를 구함

TODO. 데이터 분석을 위한 graph(x축 block size, y축 latency)

[kwjooo]

tendermint의 경우 mempool에 tx를 쌓은 후 consensus 후에 실제 tx를 실행하고 mempool에서 제거하는데, mempool에 쌓이는 속도가 consensus가 tx를 처리하는 속도보다 빠를 경우 node가 꺼져버리는 것으로 보아 대용량 tx에 대한 처리가 부족해 보입니다. mempool 한계에 따라 transaction을 받지 못한다는 자세한 에러 처리가 필요합니다.

[elon0823]

현재 방향이 tendermint 를 걷어내서 작업하기로 하였고, 해당 실험은 tendermint 에 의존적인 실험이므로 이슈를 닫습니다