1. 오래 걸리는 요청은 모두 다른 요청을 막을까?

• 요청 A가 비동기 DB 조회를 시작하고 결과를 250ms 동안 기다린다.

• 요청 A가 큰 데이터를 계산하느라 JavaScript를 250ms 동안 연속으로 실행한다.

하나의 요청이 이벤트 루프를 오래 점유하면, 같은 이벤트 루프에서 처리할 다른 요청도 지연된다.

2. 하나의 이벤트 루프로 어떻게 여러 I/O를 처리할까?

1. 요청을 받은 JavaScript가 입력을 확인하고 DB 조회를 시작한다.

2. 네트워크 응답을 기다리는 동안 현재 함수가 제어권을 돌려준다.

3. 이벤트 루프는 실행할 수 있는 다른 요청과 콜백을 처리한다.

4. DB 응답을 처리할 준비가 되면 관련 후속 코드가 실행될 차례를 얻는다.

5. JavaScript가 결과를 가공하고 응답을 만든다.

3. 어떤 장점이 있을까?

I/O를 기다리는 동안 다른 요청을 처리한다

요청마다 전용 스레드를 두는 비용을 줄일 수 있다

독립적인 I/O를 겹쳐 응답 시간을 줄인다

스트림과 함께 쓰면 큰 데이터를 나눠 처리하기 좋다

4. 어떤 단점과 제약이 있을까?

긴 실행 하나가 다른 요청의 응답 시간까지 늘린다

• 큰 JSON의 JSON.parse, JSON.stringify

• 큰 배열의 정렬과 집계

• 특정 입력에서 실행 시간이 급증하는 정규식

• 요청 처리 중 사용하는 동기 파일 I/O

비동기 호출도 스레드 풀이나 연결 풀에서 밀릴 수 있다

동시 요청을 늘릴수록 메모리와 상대 시스템의 부담도 커진다

async와 await는 CPU 작업을 다른 스레드로 보내지 않는다

Promise.all로 함수 5개를 호출하면 어떨까?

import { performance } from 'node:perf_hooks';

async function slow() {
  const end = performance.now() + 5000;
  while (performance.now() < end) {}
  console.log('slow 완료');
}

async function fast(id) {
  console.log('fast ' + id + ' 완료');
}

await Promise.all([
  slow(),
  fast(1),
  fast(2),
  fast(3),
  fast(4),
]);

console.log('전체 완료');

slow 완료
fast 1 완료
fast 2 완료
fast 3 완료
fast 4 완료
전체 완료

async function slow() {
  await new Promise(resolve => setTimeout(resolve, 5000));
  console.log('slow 완료');
}

fast 1 완료
fast 2 완료
fast 3 완료
fast 4 완료
slow 완료
전체 완료

한 스레드라도 await 사이에서는 데이터가 바뀐다

5. 단점을 줄이려면 작업을 어떻게 나눠야 할까?

짧게 나눌 수 있는 계산은 실행 기회를 양보한다

import { setImmediate as yieldToLoop } from 'node:timers/promises';

async function sumInChunks(values, size = 1000) {
  if (!Number.isInteger(size) || size < 1) {
    throw new RangeError('size must be a positive integer');
  }

  let total = 0;
  for (let offset = 0; offset < values.length; offset += size) {
    const end = Math.min(offset + size, values.length);

    for (let i = offset; i < end; i++) {
      total += values[i];
    }

    if (end < values.length) {
      await yieldToLoop();
    }
  }
  return total;
}

console.log(await sumInChunks([1, 2, 3, 4], 2)); // 10

무거운 JavaScript 연산은 워커를 검토한다

6. 어떤 상황에서 쓰기 좋고, 무엇을 측정해야 할까?

• 요청별 응답 시간과 처리량: 평균뿐 아니라 p95·p99와 오류율을 확인한다.

• 이벤트 루프 지연: monitorEventLoopDelay로 루프가 실행 기회를 얼마나 늦게 얻는지 본다. 반환되는 히스토그램의 시간 단위는 나노초이므로 밀리초로 표시할 때 1e6으로 나눈다.

• 이벤트 루프 사용률: eventLoopUtilization은 루프의 활성·유휴 시간 관점의 지표다. CPU 사용률과 동일한 값으로 해석하지 않는다.

• 풀과 대기열: DB 연결을 얻기까지의 시간, 진행 중인 작업 수, 대기열 길이와 외부 호출 시간을 함께 본다.

• 메모리: JavaScript 객체를 담는 힙, Buffer 등 외부 메모리, 프로세스 전체 메모리를 본다. 사용하지 않는 객체를 정리하는 GC가 실행 지연에 미치는 영향도 함께 확인한다.

정리