クイズ: 刻むか、移すか

큰 반복문을 조각으로 나누기만 하고 조각 사이에 아무것도 하지 않았습니다. 이벤트 루프 입장에서 달라지는 것은?

• 아무것도 달라지지 않는다 — 한 번에 돈 것과 같다
• 조각 수만큼 지연이 나뉘어 줄어든다
• 조각마다 가비지 컬렉션이 돌아 지연이 늘어난다
• 조각 경계에서 자동으로 차례가 넘어간다

4천만 번 도는 계산을 40조각으로 나누고 사이마다 setImmediate 로 양보했습니다. 총 시간은 어떻게 될까요?

• 조각 수에 비례해 크게 늘어난다
• 양보 비용만큼 조금 늘어난다
• 루프가 병렬로 처리해 줄어든다
• 정확히 같다 — 계산량이 같기 때문이다

응답 지연을 50ms 안으로 맞추고 싶습니다. 조각 크기를 정하는 근거로 맞는 것은?

• 전체 계산 시간을 CPU 코어 수로 나눈다
• 조각 수를 동시 요청 수와 같게 맞춘다
• 이벤트 루프의 한 바퀴 시간에 맞춘다
• 조각 하나를 도는 시간이 50ms 를 넘지 않게 잡는다

워커 스레드로 옮길 수 없는 일에 가장 가까운 것은?

• 요청 본문의 큰 배열을 정렬해 상위 100개를 고르는 일
• 비밀번호 해시를 여러 번 반복해 계산하는 일
• 지금 열려 있는 소켓에 직접 응답을 쓰는 일
• 이미지 바이트를 받아 크기를 줄여 돌려주는 일

실습 이미지에서 워커 하나를 띄워 빈 일감의 답을 받기까지 22ms 에서 31ms 가 걸렸습니다. 이 숫자가 설계에 주는 뜻은?

• 워커는 되도록 쓰지 않는 편이 낫다
• 기동 비용보다 가벼운 일은 옮기면 손해이고, 자주 쓰면 미리 띄워 둔다
• 워커 수를 CPU 코어 수와 같게 맞춰야 한다
• 워커에 보내는 데이터 크기를 줄여야 한다

함수를 async 로 선언하면 무거운 반복문이 루프를 막지 않게 될까요?

• 된다 — async 함수는 별도 큐에서 실행된다
• 된다 — 반환값이 프로미스라 호출자가 기다린다
• 안 된다 — await 를 만나기 전까지는 동기로 끝까지 돈다
• 안 된다 — async 함수는 스레드 풀에서 돌기 때문이다