성능 테스트는 워크로드의 성격에 따라서 의미가 크게 달라지는데, 테스트 설계나 수치가 어떻게 얻어졌는지 설명 같은 것이 없어서 아쉽네요.
예를 들어서 500만건을 처리한 후에 50건 처리를 기준으로 산술 평균 등을 취했는지, 그렇다면 메모리 사용량은 어떻게 구하셨는지, CPU 사용량의 차이는 어떻게 측정되었는지 등이 궁금하네요. (시간은 아마 wall-clock time이겠죠?)
또한, 'CPU 사용량을 봤을 때 두 언어에서 성능 차이의 대부분은 입출력(Input Output. 이하, IO) 작업인 카프카 메시지 소비 작업과 몽고 DB 도큐먼트 저장 작업에서 비롯된 것'이라는 해석이 있는데, 결과에서는 wall-clock time은 rust가 1/2 정도였고, CPU 사용량 (CPU time?)은 1/4.5라고 하셨는데, I/O에 관한 구현 방식 차이라는 얘기인 것인지, 아니면 CPU-intensive한 I/O 대상 데이터를 다루는 과정의 차이라는 것인지, 논리가 약간 이해가 안되는 점이 있습니다. 사실 CPU-intensitve한 task에 대해서 rust가 이점을 가지는 부분은 잘 알려져있어서 후자라면 사실 라이브러리의 차이를 언급할 필요성도 없는 것 같아서요. 오히려 실험에서는 CPU-intensive한 작업이라면 글에서도 언급한 asyncio/tokio 구현 비교처럼 훨씬 큰 차이가 발생했어야 했는데, I/O 때문에 성능 차이가 덜 났다고 해석해야하는 것 아닌가 싶습니다.
성능 테스트는 워크로드의 성격에 따라서 의미가 크게 달라지는데, 테스트 설계나 수치가 어떻게 얻어졌는지 설명 같은 것이 없어서 아쉽네요.
예를 들어서 500만건을 처리한 후에 50건 처리를 기준으로 산술 평균 등을 취했는지, 그렇다면 메모리 사용량은 어떻게 구하셨는지, CPU 사용량의 차이는 어떻게 측정되었는지 등이 궁금하네요. (시간은 아마 wall-clock time이겠죠?)
또한, 'CPU 사용량을 봤을 때 두 언어에서 성능 차이의 대부분은 입출력(Input Output. 이하, IO) 작업인 카프카 메시지 소비 작업과 몽고 DB 도큐먼트 저장 작업에서 비롯된 것'이라는 해석이 있는데, 결과에서는 wall-clock time은 rust가 1/2 정도였고, CPU 사용량 (CPU time?)은 1/4.5라고 하셨는데, I/O에 관한 구현 방식 차이라는 얘기인 것인지, 아니면 CPU-intensive한 I/O 대상 데이터를 다루는 과정의 차이라는 것인지, 논리가 약간 이해가 안되는 점이 있습니다. 사실 CPU-intensitve한 task에 대해서 rust가 이점을 가지는 부분은 잘 알려져있어서 후자라면 사실 라이브러리의 차이를 언급할 필요성도 없는 것 같아서요. 오히려 실험에서는 CPU-intensive한 작업이라면 글에서도 언급한 asyncio/tokio 구현 비교처럼 훨씬 큰 차이가 발생했어야 했는데, I/O 때문에 성능 차이가 덜 났다고 해석해야하는 것 아닌가 싶습니다.