요청 하나가 아니라 전부가 느려졌다 · 무엇이 막고 무엇이 안 막는가 · 퀴즈
퀴즈: 무엇이 막고 무엇이 안 막는가
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
Node 공식 문서가 libuv 스레드 풀을 쓴다고 적은 API 가 아닌 것은?
- dns.resolve4()
- crypto.pbkdf2() (비동기)
- zlib.gzip() (비동기)
- fs.readFile()
이미지 압축을 비동기로 바꾸자 루프 지연은 사라졌는데, 그 뒤로 설정 파일 읽기가 느려졌습니다. 가장 그럴듯한 원인은?
- 압축 결과가 디스크 캐시를 밀어냈다
- 비동기 압축이 파일 읽기와 같은 스레드 풀 칸을 나눠 쓴다
- 압축이 파일 디스크립터를 소진했다
- 비동기 콜백이 루프의 타이머 단계를 늦춘다
실습 이미지(Node 22.11.0, CPU 2코어)에서 같은 무게의 비동기 암호 연산 8개를 동시에 보내면 끝나는 시각이 두 덩어리로 갈라집니다. 이유는?
- CPU 가 2코어라 두 개씩 짝지어 처리된다
- 이벤트 루프가 콜백을 두 단계로 나눠 부른다
- 스레드 풀이 기본 네 칸이라 뒤 네 개가 차례를 기다린다
- 암호 연산의 결과 길이에 따라 처리 시간이 달라진다
`UV_THREADPOOL_SIZE=8` 로 올려 같은 작업 8개를 다시 재면 무엇이 달라질까요? (CPU 2코어)
- 전체가 끝나는 시각이 거의 절반으로 줄어든다
- 각 작업의 처리 시간이 그대로이고 전체도 그대로다
- 칸이 남아 오히려 전체 시간이 늘어난다
- 두 덩어리로 갈라지던 것이 사라지고 전체 시간은 거의 같다
`process.env.UV_THREADPOOL_SIZE = "16"` 을 프로그램 첫 줄에 넣었는데 아무 변화가 없습니다. 이유로 문서가 드는 것은?
- 환경 변수 이름이 대소문자를 가리기 때문이다
- 16 은 상한을 넘는 값이라 무시되기 때문이다
- 스레드 풀이 사용자 코드보다 먼저 만들어지기 때문이다
- 값이 문자열이라 숫자로 해석되지 않기 때문이다
큰 JSON 본문을 받는 엔드포인트에서 `JSON.parse` 를 스레드 풀로 옮기려 합니다. 가장 정확한 판단은?
- fs.readFile 로 읽으면 파싱도 함께 비동기가 된다
- 비동기판이 없으므로 본문 크기를 제한하는 쪽이 현실적이다
- await 를 붙이면 루프에 차례가 넘어간다
- Buffer 로 받으면 파싱이 네이티브 코드에서 처리된다