NestJS · Profiling

성능 모니터링에서 병목을 좁히는 순서

성능 문제를 고칠 때는 controller 코드를 먼저 의심하기보다, HTTP 지연을 DB, 외부 API, serialization, event loop, GC 중 어디에서 쓰는지 분해해야 한다.

01

느린 route 찾기

전체 평균이 아니라 endpoint와 status별 p95 지연을 먼저 확인한다.

02

구간 분해

guard, pipe, service, DB, 외부 호출, 응답 직렬화 시간을 나눠 측정한다.

03

병목 검증

느린 쿼리 로그, trace span, heap snapshot으로 원인 후보를 확인한다.

04

개선 비교

index 추가, cache, batch, pagination 변경 전후 같은 부하에서 지표를 비교한다.

p95
사용자 체감 지연 대부분의 사용자가 겪는 느린 응답을 보여줌
평균보다 유용
Slow query
DB 병목 index 누락, N+1, 잠금 대기 확인
ORM 로그와 DB 통계 함께 보기
Event loop lag
Node 런타임 포화 동기 계산이나 JSON 처리로 요청 처리가 막힘
worker thread나 작업 분리 검토
Heap
메모리 증가 캐시 누수, 큰 응답, listener 누적 확인
스냅샷 비교 필요

측정 기준 · 구간 시간 · DB 인덱스 점검

성능 기준선 기록 수정 전 baseline과 재현 부하 조건이 남아 있다.
구간 시간 전체 응답 시간만 있고 내부 구간 시간이 없는 상태를 피한다.
DB 인덱스 where, join, order by 기준으로 실행 계획을 확인한다.
회귀 성능 개선 후 핵심 API 지표가 모니터링에 남는다.