Node.js 백엔드 애플리케이션 환경에서 유효성 검사가 성능에 큰 영향이 있을까?
(jhyeok.com)- JavaScript 및 Node.js 환경에서 유효성 검사 라이브러리인 Joi는 다른 라이브러리보다 성능이 느림
- Joi를 다른 라이브러리로 교체하면 백엔드 환경에서 성능 향상이 기대됨
- 백엔드 애플리케이션에서 유의미한 성능 차이가 나타날 수 있는지 테스트
- k6을 사용해서 테스트를 진행하며, lodash와 class-transformer도 함께 테스트
- 성능 테스트 결과:
- native vs lodash: 성능 차이 없음
- object literal vs class-transformer: 성능 차이 없음
- non-validation vs Joi: Joi의 느린 성능에도 성능 차이가 나타나지 않음
- 성능은 중요하지만 이미 진행 중인 프로젝트에서 변경 시 투자한 시간 대비 성능 차이를 느끼지 못할 수 있음
작성자분은 병목 상황을 개선하는게 목표가 아니라 실 상황과 유사한 환경에선 유효성 검사 라이브러리의 성능차는 크게 유의미하지 않다를 주장하는게 아닐까 싶어요.
실 상황을 본문에서 설명한 io bound task만 있는 서비스가 아니라 cpu bound task 서비스라고 가정한다면 어떨까요?
실제 환경의 서비스는 생각보다 복합적입니다. ui를 그리는데 필요한 데이터 서빙 api만 서버가 아닙니다
Validation 및 JSON serialization 작업이 메인 스레드에서 이루어지는 연산이다보니, 마냥 우습게 볼 일이 아닙니다. TS 백엔드 진영에선 가장 보편적으로 쓰이는게 class-validator/class-transformer 입니다. 그리고 이 친구의 초당 검증 가능량이 4MB 정도인데, 이 말은 메인 스레드에서 초당 4MB 이상 처리할 수 없다는 뜻이거든요.
DB 입출력이야 메인이 아닌 백그라운드 스레드에서 동작하는 것인지라, 백엔드 서버 기준 (TS 서버 기준) 동접에 크게 영향을 주지는 않습니다. 서비스 성격에 따라 한 번에 전송되는 DTO 양이 크면, 오히려 validation 느린게 더 무섭습니다 (실제로 건당 데이터가 큰 서비스를 만들었을 때, NestJS 동접이 한 자릿수이던 사례도 있ㅅ브니다).
마치 성능 향상이 없지만 있는것 처럼 포장되었다는 것 같지만 사실 애초에 db쪽이 병목인데 병목이 아닌 지점을 개선하는것을 중심으로 작성된게 오해를 만들 것 같네요
윗 분 말씀대로 DB 입출력이 왜 들어갔는지 이해하기 힘든 벤치입니다. 그리고 느린 validation 및 serialization은 request DTO보단, response DTO에서 서버 성능에 끼치는 해악이 더 큽니다. 마지막으로 이런 벤치마크 실험을 할 때는 DTO를 하나만 두고 할 게 아니라, 다양한 종류를 두고 실험해야 합니다.
실제로 DB I/O가 없고, 다양한 구조의 DTO를 실험했을 때는 그 결과가 상이합니다.
- 서버 사이드 벤치마크: https://github.com/samchon/nestia/…%20Core(TM)%20i5-1135G7%20%40%202.40GHz
- 순수 Validation 속도 벤치마크: https://github.com/samchon/typia/…%20Core(TM)%20i5-1135G7%20%40%202.40GHz