测验：什么会堵，什么不会

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 로 받으면 파싱이 네이티브 코드에서 처리된다