Node 성능 최적화는 실제 병목을 찾기 위해 측정에서 시작합니다. 절대 추측하지 마세요. CPU 사용량, event loop, 메모리를 프로파일링한 다음 표적화된 수정을 적용합니다. 황금률: 먼저 프로파일링하고, 실제로 느린 것을 최적화하라.
node --prof app.js
node --prof-process isolate-*.
npx clinic doctor -- node app.js
npx clinic flame -- node app.js
node --inspect app.js
이들은 시간이 어디로 가는지 드러냅니다. flame graph는 어떤 함수가 CPU를 지배하는지 보여주므로 올바른 것을 최적화할 수 있습니다.
// ❌ synchronous CPU-heavy work blocks ALL request handling
function handler(req, res) {
const result = heavyComputation(); // freezes the event loop → every request stalls
res.json(result);
}
Node는 JS가 단일 스레드이므로 긴 동기 작업이 모든 것을 블로킹합니다. **event loop 지연(lag)**을 모니터링하세요(예: perf_hooks의 monitorEventLoopDelay). 지연 상승은 무언가가 loop를 블로킹하고 있다는 뜻입니다. CPU 작업을 worker thread나 큐로 위임하여 수정합니다.
✓ Fix N+1 database queries — the most common real bottleneck (batch/join instead)
✓ Add caching (in-memory/Redis) for repeated expensive operations
✓ Add database indexes for slow queries
✓ Use streams for large data instead of buffering it all in memory
✓ Parallelize independent async ops with Promise.all (avoid await waterfalls)
✓ Offload CPU-bound work to worker threads (keep the event loop free)
✓ Use connection pooling for DB/HTTP
✓ Enable gzip/brotli compression for responses
Many "Node is slow" problems are actually slow DB queries (N+1, missing indexes)
or external API latency — profiling reveals this so you fix the real cause.
npx autocannon http://localhost:3000 # measure requests/sec, latency before & after
각 변경의 전후를 측정하여 최적화가 실제로 도움이 되었는지 확인하세요.
성능 작업은 측정에 기반할 때만 효과적입니다. 잘못된 것을 최적화하면 노력을 낭비하고 복잡성을 더합니다.
프로파일링 방법(CPU에는 clinic.js/flame graph/DevTools, event loop 지연 모니터링, 힙 분석)을 알면 실제 병목을 찾을 수 있는데, Node에서는 흔히 블로킹된 event loop(worker thread로 수정)나 느린 데이터베이스 쿼리(N+1, 누락된 인덱스 — 자주 진짜 원인)입니다.
캐싱, 스트리밍, 병렬성, 풀링과 결합하고 부하 테스트로 검증하는 — 이 측정 후 수정 규율이 굼뜬 서비스를 빠르고 확장 가능한 것으로 바꿉니다.