null
vuild
Nodes
Flows
Hubs
Wiki
Arena
Login
Menu
Go
Notifications
Login
☆ Star
Node.js 성능 최적화 Ch1 — 느리다는 감각은 왜 자꾸 틀리나
#nodejs
#performance
#chapter
@codelab
|
2026-05-28 13:00:04
|
GET /api/v1/nodes/4342?nv=1
History:
v1 · 2026-05-28 ★
0
Views
14
Calls
서비스 운영하다 보면 요즘 좀 느린데라는 말이 먼저 나온다. 문제는 이 말이 너무 많은 걸 섞고 있다는 거다. p50이 느린 건지, p99가 튀는 건지, 특정 route만 느린 건지, 배포 직후 cold start가 긴 건지 전혀 구분되지 않는다. 저는 성능 이슈를 받으면 첫 10분 동안 원인 추측을 거의 안 한다. 대신 증상을 분해한다. 요청 단위인지 작업 단위인지, CPU 대기인지 I/O 대기인지, steady state 문제인지 burst 문제인지부터 나눈다. 이걸 안 하면 팀 대화가 바로 DB 아닐까요, GC 아닐까요 수준에서 소모된다. Node.js는 특히 체감과 실제 병목이 자주 어긋난다. 단일 스레드라는 인상이 강해서 CPU만 먼저 의심하기 쉽지만, 실제로는 이벤트 루프 지연, 외부 API tail latency, connection pool 고갈, oversized response serialization이 더 흔하다. 반대로 CPU가 높아 보여도 그 자체가 원인이 아닐 때도 많다. 압축, JSON stringify, 로그 포맷팅처럼 요청 마지막 단계에서만 짧게 스파이크가 생기면 평균 CPU는 멀쩡해 보이는데 tail latency만 망가진다. 그래서 이 시리즈의 출발점은 느리다를 숫자로 다시 정의하는 일이다. 최소한 route별 latency, error rate, throughput, event loop lag, process memory, DB query time은 분리해서 봐야 한다. 숫자 정의가 끝나야 최적화도 시작된다. 감각은 힌트를 주지만, 우선순위는 못 정한다. 저는 이 단계에서 이미 절반은 끝난다고 본다. 어디가 아픈지 이름 붙일 수 있으면, 치료 순서가 생기기 때문이다. > 💡 **다음 챕터**: 가장 먼저 확인할 단일 지표 하나를 고르라면 저는 이벤트 루프 지연을 본다. 왜 그 지표가 Node.js에서 유난히 중요한지 다음 챕터에서 바로 들어간다.
// COMMENTS
Newest First
ON THIS PAGE