노드 JS 내부
- Mary-Kate Olsen원래의
- 2024-11-19 08:15:03375검색
식당에 가는데 한 셰프가 "나는 동시에 수백 명을 위한 요리를 할 수 있고 여러분 중 누구도 배고프지 않을 것이다"라고 약속한다고 가정해 보세요. 불가능하게 들리겠죠? 이 단일 수표를 여러 주문을 모두 관리하고 모든 고객에게 음식을 제공하는 Node JS로 간주할 수 있습니다.
누군가에게 "Node JS가 무엇인가요?"라는 질문을 하면 항상 "Node JS는 브라우저 환경 외부에서 JavaScript를 실행하는 데 사용되는 런타임입니다."라는 대답이 돌아옵니다.
그런데 런타임이란 무엇을 의미할까요?... 런타임 환경은 코드 실행이 특정 프로그래밍 언어로 작성되는 소프트웨어 인프라입니다. 여기에는 코드 실행, 오류 처리, 메모리 관리를 위한 모든 도구, 라이브러리 및 기능이 포함되어 있으며 기본 운영 체제 또는 하드웨어와 상호 작용할 수 있습니다.
Node JS에는 이 모든 것이 있습니다.
코드를 실행하기 위한 Google V8 엔진.
fs, crypto, http 등 핵심 라이브러리 및 API
비동기 및 비차단 I/O 작업을 지원하는 Libuv 및 이벤트 루프와 같은 인프라
이제 Node JS를 런타임이라고 부르는 이유를 알 수 있습니다.
이 런타임은 두 개의 독립적인 종속성인 V8과 libuv로 구성됩니다.
V8은 구글 크롬에서도 사용되는 엔진으로 구글에서 개발, 관리하고 있습니다. Node JS에서는 JavaScript 코드를 실행합니다. node index.js 명령을 실행하면 Node JS가 이 코드를 V8 엔진에 전달합니다. V8은 이 코드를 처리하고 실행한 후 결과를 제공합니다. 예를 들어 코드가 "Hello, World!"를 기록하는 경우 V8은 콘솔에서 이를 발생시키는 실제 실행을 처리합니다.
libuv 라이브러리에는 네트워킹, I/O 작업 또는 시간 관련 작업과 같은 기능이 필요할 때 운영 체제에 액세스할 수 있는 C 코드가 포함되어 있습니다. Node JS와 운영 체제 사이의 브리지 역할을 합니다.
libuv는 다음 작업을 처리합니다.
파일 시스템 작업: 파일 읽기 또는 쓰기(fs.readFile, fs.writeFile).
네트워킹: HTTP 요청, 소켓 처리 또는 서버 연결
타이머: setTimeout 또는 setInterval과 같은 기능을 관리합니다.
파일 읽기와 같은 작업은 Libuv 스레드 풀에 의해 처리되고, 타이머는 Libuv 타이머 시스템에 의해 처리되며, 네트워크 호출은 OS 수준 API에 의해 처리됩니다.
Node JS는 단일 스레드인가요?
다음 예를 보세요.
const fs = require('fs');
const path = require('path');
const filePath = path.join(__dirname, 'file.txt');
const readFileWithTiming = (index) => {
const start = Date.now();
fs.readFile(filePath, 'utf8', (err, data) => {
if (err) {
console.error(`Error reading the file for task ${index}:`, err);
return;
}
const end = Date.now();
console.log(`Task ${index} completed in ${end - start}ms`);
});
};
const startOverall = Date.now();
for (let i = 1; i <= 4; i++) {
readFileWithTiming(i);
}
process.on('exit', () => {
const endOverall = Date.now();
console.log(`Total execution time: ${endOverall - startOverall}ms`);
});
동일한 파일을 4번 읽고 있으며 해당 파일을 읽는 시간을 기록하고 있습니다.
이 코드는 다음과 같은 결과를 얻습니다.
Task 1 completed in 50ms Task 2 completed in 51ms Task 3 completed in 52ms Task 4 completed in 53ms Total execution time: 54ms
4개 파일 모두 거의 50ms에 읽기를 완료한 것을 볼 수 있습니다. Node JS가 단일 스레드인 경우 어떻게 이 모든 파일 읽기 작업이 동시에 완료되나요?
이 질문은 libuv 라이브러리가 스레드 풀을 사용한다는 답변입니다. 스레드 풀은 스레드 묶음입니다. 기본적으로 스레드 풀 크기는 4이므로 libuv에서 한 번에 4개의 요청을 처리할 수 있습니다.
한 파일을 4번 읽는 대신 이 파일을 6번 읽는 또 다른 시나리오를 생각해 보세요.
const fs = require('fs');
const path = require('path');
const filePath = path.join(__dirname, 'file.txt');
const readFileWithTiming = (index) => {
const start = Date.now();
fs.readFile(filePath, 'utf8', (err, data) => {
if (err) {
console.error(`Error reading the file for task ${index}:`, err);
return;
}
const end = Date.now();
console.log(`Task ${index} completed in ${end - start}ms`);
});
};
const startOverall = Date.now();
for (let i = 1; i <= 4; i++) {
readFileWithTiming(i);
}
process.on('exit', () => {
const endOverall = Date.now();
console.log(`Total execution time: ${endOverall - startOverall}ms`);
});
출력은 다음과 같습니다.
Task 1 completed in 50ms Task 2 completed in 51ms Task 3 completed in 52ms Task 4 completed in 53ms Total execution time: 54ms
읽기 작업 1과 2가 완료되고 스레드 1과 2가 해제되었다고 가정합니다.
처음 4번에서는 파일을 읽는 데 거의 같은 시간이 걸리지만 이 파일을 5번째와 6번째로 읽으면 처음 4번의 읽기 작업보다 읽기 작업을 완료하는 데 거의 두 배의 시간이 걸립니다. .
이는 스레드 풀 크기가 기본적으로 4이므로 4개의 읽기 작업이 동시에 처리되지만 다시 2(5번째와 6번째) 파일을 읽고 모든 스레드에 작업이 있기 때문에 libuv가 기다립니다. 4개의 스레드 중 하나가 실행을 완료하면 5번째 읽기 작업이 해당 스레드로 처리되고 6번째 읽기 작업도 동일하게 수행됩니다. 그래서 시간이 더 걸리는 이유입니다.
그래서 Node JS는 단일 스레드가 아닙니다.
그런데 왜 어떤 사람들은 싱글스레드라고 부르는 걸까요?
메인 이벤트 루프가 단일 스레드이기 때문입니다. 이 스레드는 비동기 콜백 처리 및 작업 조정을 포함하여 Node JS 코드 실행을 담당합니다. 파일 I/O와 같은 차단 작업을 직접 처리하지 않습니다.
코드 실행 흐름은 이렇습니다.
- 동기 코드(V8):
Node.js는 V8 JavaScript 엔진을 사용하여 모든 동기(차단) 코드를 한 줄씩 실행합니다.
- 비동기 작업 위임:
fs.readFile, setTimeout 또는 http 요청과 같은 비동기 작업은 Libuv 라이브러리 또는 기타 하위 시스템(예: OS)으로 전송됩니다.
- 작업 실행:
파일 읽기와 같은 작업은 Libuv 스레드 풀에 의해 처리되고, 타이머는 Libuv 타이머 시스템에 의해 처리되며, 네트워크 호출은 OS 수준 API에 의해 처리됩니다.
- 콜백 대기 중:
비동기 작업이 완료되면 관련 콜백이 이벤트 루프의 대기열로 전송됩니다.
- 이벤트 루프가 콜백을 실행합니다:
이벤트 루프는 대기열에서 콜백을 선택하여 하나씩 실행하여 비차단 실행을 보장합니다.
process.env.UV_THREADPOOL_SIZE = 8을 사용하여 스레드 풀 크기를 변경할 수 있습니다.
이제는 스레드 수를 높게 설정하면 많은 요청도 처리할 수 있을 것이라고 생각합니다. 이에 대해 저와 같은 생각을 하시길 바랍니다.
그런데, 우리가 생각했던 것과는 반대네요.
특정 한도 이상으로 스레드 수를 늘리면 코드 실행 속도가 느려집니다.
다음 예를 보세요.
const fs = require('fs');
const path = require('path');
const filePath = path.join(__dirname, 'file.txt');
const readFileWithTiming = (index) => {
const start = Date.now();
fs.readFile(filePath, 'utf8', (err, data) => {
if (err) {
console.error(`Error reading the file for task ${index}:`, err);
return;
}
const end = Date.now();
console.log(`Task ${index} completed in ${end - start}ms`);
});
};
const startOverall = Date.now();
for (let i = 1; i <= 4; i++) {
readFileWithTiming(i);
}
process.on('exit', () => {
const endOverall = Date.now();
console.log(`Total execution time: ${endOverall - startOverall}ms`);
});
출력:
높은 스레드 풀 크기(100스레드)
Task 1 completed in 50ms Task 2 completed in 51ms Task 3 completed in 52ms Task 4 completed in 53ms Total execution time: 54ms
이제 다음 출력은 스레드 풀 크기를 4(기본 크기)로 설정한 경우입니다.
기본 스레드 풀 크기 사용(4스레드)
const fs = require('fs');
const path = require('path');
const filePath = path.join(__dirname, 'file.txt');
const readFileWithTiming = (index) => {
const start = Date.now();
fs.readFile(filePath, 'utf8', (err, data) => {
if (err) {
console.error(`Error reading the file for task ${index}:`, err);
return;
}
const end = Date.now();
console.log(`Task ${index} completed in ${end - start}ms`);
});
};
const startOverall = Date.now();
for (let i = 1; i <= 6; i++) {
readFileWithTiming(i);
}
process.on('exit', () => {
const endOverall = Date.now();
console.log(`Total execution time: ${endOverall - startOverall}ms`);
});
총 실행 시간이 100ms 차이가 나는 것을 확인할 수 있습니다. 총 실행 시간(스레드 풀 크기 4)은 600ms이고 총 실행 시간(스레드 풀 크기 100)은 700ms입니다. 따라서 스레드 풀 크기 4는 시간이 덜 걸립니다.
왜 스레드 수가 많아 != 더 많은 작업을 동시에 처리할 수 있나요?
첫 번째 이유는 각 스레드마다 고유한 스택 및 리소스 요구 사항이 있다는 것입니다. 스레드 수를 늘리면 결국 메모리 부족 또는 CPU 리소스 부족 현상이 발생하게 됩니다.
두 번째 이유는 운영 체제가 스레드를 예약해야 한다는 것입니다. 스레드가 너무 많으면 OS가 스레드 간 전환(컨텍스트 전환)에 많은 시간을 소비하게 되어 성능이 향상되기는커녕 오버헤드가 추가되고 속도가 느려집니다.
이제 확장성과 고성능을 달성하기 위해 스레드 풀 크기를 늘리는 것이 아니라 클러스터링과 같은 올바른 아키텍처를 사용하고 작업 특성(I/O 대 CPU 바인딩)을 이해하는 것이라고 말할 수 있습니다. ) 및 Node.js의 이벤트 중심 모델이 작동하는 방식을 알아보세요.
읽어주셔서 감사합니다.
위 내용은 노드 JS 내부의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!