LabHub
배우기 러닝패스 코스

요청 하나가 아니라 전부가 느려졌다 · 무엇이 막고 무엇이 안 막는가 · 퀴즈

퀴즈: 무엇이 막고 무엇이 안 막는가

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. Node 공식 문서가 libuv 스레드 풀을 쓴다고 적은 API 가 아닌 것은?

    1. dns.resolve4()
    2. crypto.pbkdf2() (비동기)
    3. zlib.gzip() (비동기)
    4. fs.readFile()
  2. 이미지 압축을 비동기로 바꾸자 루프 지연은 사라졌는데, 그 뒤로 설정 파일 읽기가 느려졌습니다. 가장 그럴듯한 원인은?

    1. 압축 결과가 디스크 캐시를 밀어냈다
    2. 비동기 압축이 파일 읽기와 같은 스레드 풀 칸을 나눠 쓴다
    3. 압축이 파일 디스크립터를 소진했다
    4. 비동기 콜백이 루프의 타이머 단계를 늦춘다
  3. 실습 이미지(Node 22.11.0, CPU 2코어)에서 같은 무게의 비동기 암호 연산 8개를 동시에 보내면 끝나는 시각이 두 덩어리로 갈라집니다. 이유는?

    1. CPU 가 2코어라 두 개씩 짝지어 처리된다
    2. 이벤트 루프가 콜백을 두 단계로 나눠 부른다
    3. 스레드 풀이 기본 네 칸이라 뒤 네 개가 차례를 기다린다
    4. 암호 연산의 결과 길이에 따라 처리 시간이 달라진다
  4. `UV_THREADPOOL_SIZE=8` 로 올려 같은 작업 8개를 다시 재면 무엇이 달라질까요? (CPU 2코어)

    1. 전체가 끝나는 시각이 거의 절반으로 줄어든다
    2. 각 작업의 처리 시간이 그대로이고 전체도 그대로다
    3. 칸이 남아 오히려 전체 시간이 늘어난다
    4. 두 덩어리로 갈라지던 것이 사라지고 전체 시간은 거의 같다
  5. `process.env.UV_THREADPOOL_SIZE = "16"` 을 프로그램 첫 줄에 넣었는데 아무 변화가 없습니다. 이유로 문서가 드는 것은?

    1. 환경 변수 이름이 대소문자를 가리기 때문이다
    2. 16 은 상한을 넘는 값이라 무시되기 때문이다
    3. 스레드 풀이 사용자 코드보다 먼저 만들어지기 때문이다
    4. 값이 문자열이라 숫자로 해석되지 않기 때문이다
  6. 큰 JSON 본문을 받는 엔드포인트에서 `JSON.parse` 를 스레드 풀로 옮기려 합니다. 가장 정확한 판단은?

    1. fs.readFile 로 읽으면 파싱도 함께 비동기가 된다
    2. 비동기판이 없으므로 본문 크기를 제한하는 쪽이 현실적이다
    3. await 를 붙이면 루프에 차례가 넘어간다
    4. Buffer 로 받으면 파싱이 네이티브 코드에서 처리된다