Node.js 애플리케이션 프로파일링 (심화)

내장 프로파일러는 일정 간격(기본 1ms)마다 현재 콜 스택을 샘플링한다. 그래서 샘플 비중 ≈ 그 함수가 메인 스레드를 점유한 시간이다. Node 의 핵심 통증은 동기 CPU 작업이 이벤트 루프를 막는 것 이므로, 비중 1위 함수가 *Sync 라면 거의 확실히 범인이다.

 [JavaScript]:
   ticks  total  nonlib   name
     1.6%   ...    pbkdf2Sync                <-- 동기 CPU
     0.4%   ...    JSON.stringify

보고서 하단의 Bottom up (heavy) profile 은 자식 → 부모 순서로 출력한다. 같은 함수가 여러 부모에서 불릴 때 어느 핸들러에서 들어왔는가 를 빠르게 찾는 유일한 방법.

 [Bottom up (heavy) profile]:
   ticks parent  name
      9   55.0%  pbkdf2Sync
      9  100.0%    Module._compile -> /auth

이걸 보면 "pbkdf2Sync 의 부하가 100% /auth 핸들러에서 발생" 임을 단번에 알 수 있다.

프로파일링이 "여기 동기다" 라고 알려주면 다음 둘 중 하나로 분리한다.

// (1) 비동기 콜백 버전 사용
import { pbkdf2 } from 'crypto';
import { promisify } from 'util';
const pbkdf2Async = promisify(pbkdf2);
await pbkdf2Async(password, salt, 10000, 512, 'sha512');

// (2) Worker 풀로 위임 (CPU bound)
import { Worker } from 'worker_threads';
// 또는 piscina, workerpool 등의 풀 라이브러리

IO 바운드면 (1) — 콜백/Promise 가 충분. CPU 바운드면 (2) — Worker 가 필요. pbkdf2 는 둘 다 가능하지만, 키 길이/반복 수가 크면 Worker 가 우세.

[감점 답변] "가장 느린 함수를 찾는다". [좋은 답변] (1) node --prof 로 부하 시간 동안 틱 수집 → (2) --prof-process 로 보고서 → (3) JavaScript 섹션 상위 + Bottom up 두 곳을 본다. 상위가 *Sync/정규식/큰 JSON 류라면 동기 CPU 차단 이고, 부모 트레이스로 어떤 핸들러 인지 좁힌다. (4) 그 핸들러를 promisify 또는 Worker 로 분리. "느린 함수" 가 아니라 "동기 함수" 가 핵심.

[감점 답변] "비동기로 바꿨는데 왜 안 되지?". [좋은 답변] pbkdf2 는 내부적으로 libuv 스레드 풀(기본 4) 위에서 돈다. 동시에 5개 이상 들어오면 큐잉되어 결국 CPU 가 직렬화된다. 풀 크기를 UV_THREADPOOL_SIZE 로 늘리거나, 진짜 CPU 바운드라면 Worker pool 로 옮기고 코어 수만큼 분산한다. 즉 "비동기 = 무료" 가 아니라 어떤 자원 위에서 비동기인지를 본다.

[감점 답변] "성능에 영향이 적으니 그냥 켜자". [좋은 답변] 항상 켜는 건 권장하지 않는다. 디스크/IO 비용과 1~3% 오버헤드, 그리고 개인정보가 함수명/스택에 노출 가능성. 대신 (1) 부하 테스트 환경에서 상시, (2) 운영에서는 inspector + Chrome DevTools, 또는 Continuous Profiler (Pyroscope/Datadog) 처럼 샘플링 기반 도구를 쓴다.