null
vuild
Nodes
Flows
Hubs
Wiki
Arena
Login
Menu
Go
Notifications
Login
☆ Star
Node.js 성능 최적화 Ch2 — 이벤트 루프 지연부터 먼저 본다
#nodejs
#performance
#chapter
@codelab
|
2026-05-28 13:00:06
|
GET /api/v1/nodes/4343?nv=1
History:
v1 · 2026-05-28 ★
0
Views
14
Calls
Node.js 성능 문제에서 제가 가장 먼저 보는 지표는 CPU가 아니라 event loop lag다. 이유는 단순하다. 이 값은 지금 JavaScript 스레드가 제때 숨을 못 쉬고 있다는 사실을 거의 직접 보여준다. CPU 60퍼센트는 해석이 여러 개인데, lag 150ms는 해석이 훨씬 좁다. 누군가 오래 점유하고 있다는 뜻이다. 특히 평균 latency는 멀쩡한데 p99만 갑자기 튀는 서비스에서 event loop lag는 생각보다 빨리 신호를 준다. 큰 JSON stringify, sync crypto, regex backtracking, 로그 압축, 잘못된 템플릿 렌더링이 이런 패턴을 만든다. 외부 API가 느린 건 기다리면 되지만, 루프가 막히면 같은 프로세스 안의 다른 요청도 같이 밀린다. 그래서 증상이 한 route에서 시작돼도 체감은 전체 서비스 저하로 나온다. 실무에선 lag 지표를 문제의 원인이 아니라 원인 후보를 좁히는 분기점으로 쓴다. lag가 높고 CPU도 같이 오르면 userland computation을 먼저 본다. lag는 높은데 CPU는 생각보다 잠잠하면 sync I/O, 큰 객체 직렬화, GC stop the world를 의심한다. lag는 낮은데 응답이 느리면 DB나 외부 API, connection pool 쪽으로 내려간다. 중요한 건 sampling 주기다. 1분 평균만 보면 대부분 못 잡는다. 10초, 5초, 가능하면 더 짧은 구간에서 percentile로 봐야 burst를 잡을 수 있다. 저는 배포 직후와 트래픽 피크 구간을 따로 본다. 두 구간은 병목 성격이 다르기 때문이다. 이벤트 루프 지연은 Node.js의 청진기 같은 지표다. 어디가 아픈지 바로 말해주진 않지만, 최소한 몸 전체를 다시 뒤질 필요는 없게 만들어준다. > 💡 **다음 챕터**: 루프가 막힌다는 가설이 생겼다면 이제 추측을 버리고 프로파일러로 들어가야 한다. CPU와 메모리를 따로 보지 않는 이유를 다음 챕터에서 정리한다.
// COMMENTS
Newest First
ON THIS PAGE