# Node.js 백엔드 애플리케이션 환경에서 유효성 검사가 성능에 큰 영향이 있을까?

> Clean Markdown view of GeekNews topic #10331. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=10331](https://news.hada.io/topic?id=10331)
- GeekNews Markdown: [https://news.hada.io/topic/10331.md](https://news.hada.io/topic/10331.md)
- Type: news
- Author: [koeyh](https://news.hada.io/@koeyh)
- Published: 2023-08-14T09:23:02+09:00
- Updated: 2023-08-14T09:23:02+09:00
- Original source: [jhyeok.com](https://jhyeok.com/nodejs-validation-performance/)
- Points: 12
- Comments: 8

## Topic Body

- JavaScript 및 Node.js 환경에서 유효성 검사 라이브러리인 Joi는 다른 라이브러리보다 성능이 느림  
    - Joi를 다른 라이브러리로 교체하면 백엔드 환경에서 성능 향상이 기대됨  
- 백엔드 애플리케이션에서 유의미한 성능 차이가 나타날 수 있는지 테스트  
    - k6을 사용해서 테스트를 진행하며, lodash와 class-transformer도 함께 테스트  
- 성능 테스트 결과:  
    - native vs lodash: 성능 차이 없음  
    - object literal vs class-transformer: 성능 차이 없음  
    - non-validation vs Joi: Joi의 느린 성능에도 성능 차이가 나타나지 않음  
- 성능은 중요하지만 이미 진행 중인 프로젝트에서 변경 시 투자한 시간 대비 성능 차이를 느끼지 못할 수 있음

## Comments



### Comment 18267

- Author: winterjung
- Created: 2023-08-16T10:20:47+09:00
- Points: 3

작성자분은 병목 상황을 개선하는게 목표가 아니라 실 상황과 유사한 환경에선 유효성 검사 라이브러리의 성능차는 크게 유의미하지 않다를 주장하는게 아닐까 싶어요.

### Comment 18276

- Author: ddddddd
- Created: 2023-08-16T12:08:15+09:00
- Points: 1
- Parent comment: 18267
- Depth: 1

실 상황을 본문에서 설명한 io bound task만 있는 서비스가 아니라 cpu bound task 서비스라고 가정한다면 어떨까요?  
실제 환경의 서비스는 생각보다 복합적입니다. ui를 그리는데 필요한 데이터 서빙 api만 서버가 아닙니다

### Comment 18272

- Author: samchon
- Created: 2023-08-16T11:46:20+09:00
- Points: 1
- Parent comment: 18267
- Depth: 1

Validation 및 JSON serialization 작업이 메인 스레드에서 이루어지는 연산이다보니, 마냥 우습게 볼 일이 아닙니다. TS 백엔드 진영에선 가장 보편적으로 쓰이는게 class-validator/class-transformer 입니다. 그리고 이 친구의 초당 검증 가능량이 4MB 정도인데, 이 말은 메인 스레드에서 초당 4MB 이상 처리할 수 없다는 뜻이거든요.  
  
DB 입출력이야 메인이 아닌 백그라운드 스레드에서 동작하는 것인지라, 백엔드 서버 기준 (TS 서버 기준) 동접에 크게 영향을 주지는 않습니다. 서비스 성격에 따라 한 번에 전송되는 DTO 양이 크면, 오히려 validation 느린게 더 무섭습니다 (실제로 건당 데이터가 큰 서비스를 만들었을 때, NestJS 동접이 한 자릿수이던 사례도 있ㅅ브니다).

### Comment 18275

- Author: ddddddd
- Created: 2023-08-16T12:05:08+09:00
- Points: 1
- Parent comment: 18272
- Depth: 2

동의합니다 작성자분이 주장하는 "실 상황에서" 라고 전제하기엔 예시로 든 실 상황이 너무 편협합니다.

### Comment 18252

- Author: samchon
- Created: 2023-08-15T13:44:33+09:00
- Points: 4

윗 분 말씀대로 DB 입출력이 왜 들어갔는지 이해하기 힘든 벤치입니다. 그리고 느린 validation 및 serialization은 request DTO보단, response DTO에서 서버 성능에 끼치는 해악이 더 큽니다. 마지막으로 이런 벤치마크 실험을 할 때는 DTO를 하나만 두고 할 게 아니라, 다양한 종류를 두고 실험해야 합니다.  
  
실제로 DB I/O가 없고, 다양한 구조의 DTO를 실험했을 때는 그 결과가 상이합니다.  
   
- 서버 사이드 벤치마크:  https://github.com/samchon/nestia/tree/master/benchmark/results/11th%20Gen%20Intel(R)%20Core(TM)%20i5-1135G7%20%40%202.40GHz  
- 순수 Validation 속도 벤치마크: https://github.com/samchon/typia/tree/master/benchmark/results/11th%20Gen%20Intel(R)%20Core(TM)%20i5-1135G7%20%40%202.40GHz

### Comment 18248

- Author: ddddddd
- Created: 2023-08-15T12:17:29+09:00
- Points: 1

애초에 db 연결쪽이 병목인것같은데 주제가 잘못된게아닌가싶습니다

### Comment 18249

- Author: ddddddd
- Created: 2023-08-15T12:18:22+09:00
- Points: 2
- Parent comment: 18248
- Depth: 1

마치 성능 향상이 없지만 있는것 처럼 포장되었다는 것 같지만 사실 애초에 db쪽이 병목인데 병목이 아닌 지점을 개선하는것을 중심으로 작성된게 오해를 만들 것 같네요

### Comment 18250

- Author: ddddddd
- Created: 2023-08-15T12:19:28+09:00
- Points: 2
- Parent comment: 18249
- Depth: 2

대부분의 환경에서 성능 향상은 병목 지점을 해소하는것을 의미합니다 유효성 검사를 최적화할 때는 유효성 검사 쪽이 병목임이 식별된 후여야겠지요