일반적으로 Node.js는 10,000개의 동시 요청을 어떻게 처리합니까?

일반적으로 Node.js는 10,000개의 동시 요청을 어떻게 처리합니까?

Node.js는 단일 스레드와 이벤트 루프를 사용하여 요청을 한 번에 하나만 처리하는 것으로 알고 있습니다(이는 비차단).그럼에도 불구하고, 10,000개의 동시 요청을 어떻게 처리할 수 있을까요?이벤트 루프가 모든 요청을 처리합니까?너무 오래 걸리지 않을까요?

어떻게 멀티스레드 웹 서버보다 빠를 수 있는지 이해할 수 없습니다.멀티스레드 웹 서버는 리소스(메모리, CPU)가 더 비쌀 것으로 알고 있지만 그래도 더 빠르지 않을까요?제가 틀렸을 수도 있습니다. 이 단일 스레드가 많은 요청에서 어떻게 더 빠르며, 10,000개와 같은 많은 요청을 처리할 때 일반적으로 수행되는 작업(고급 수준)에 대해 설명해 주십시오.

또한, 단일 스레드가 그렇게 많은 양으로 원활하게 확장될 수 있습니까?이제 막 Node.js를 배우기 시작했다는 것을 기억해주세요.

이 질문을 해야 한다면 대부분의 웹 응용 프로그램/서비스가 무엇을 하는지 잘 모를 것입니다.여러분은 아마 모든 소프트웨어가 다음과 같이 한다고 생각할 것입니다.

user do an action
       │
       v
 application start processing action
   └──> loop ...
          └──> busy processing
 end loop
   └──> send result to user

그러나 이것은 웹 응용프로그램 또는 실제로 백엔드로 데이터베이스를 사용하는 응용프로그램의 작동 방식이 아닙니다.웹 앱은 다음을 수행합니다.

user do an action
       │
       v
 application start processing action
   └──> make database request
          └──> do nothing until request completes
 request complete
   └──> send result to user

이 시나리오에서 소프트웨어는 실행 시간의 대부분을 0% CPU 시간을 사용하여 데이터베이스가 반환될 때까지 기다립니다.

멀티스레드 네트워크 앱:

멀티스레드 네트워크 애플리케이션은 다음과 같이 위의 워크로드를 처리합니다.

request ──> spawn thread
              └──> wait for database request
                     └──> answer request
request ──> spawn thread
              └──> wait for database request
                     └──> answer request
request ──> spawn thread
              └──> wait for database request
                     └──> answer request

따라서 스레드는 대부분의 시간을 0% CPU를 사용하여 데이터베이스가 데이터를 반환할 때까지 기다립니다.이 과정에서 각 스레드에 대해 완전히 별도의 프로그램 스택을 포함하는 스레드에 필요한 메모리를 할당해야 했습니다.또한, 그들은 전체 프로세스를 시작하는 것만큼 비싸지는 않지만 여전히 정확하게 저렴하지 않은 스레드를 시작해야 합니다.

단일 스레드 이벤트 루프

우리는 대부분의 시간을 0% CPU를 사용하기 때문에 CPU를 사용하지 않을 때 코드를 실행하는 것이 어떻습니까?이렇게 하면 각 요청은 여전히 멀티스레드 애플리케이션과 동일한 양의 CPU 시간을 얻을 수 있지만 스레드를 시작할 필요는 없습니다.그래서 우리는 이렇게 합니다.

request ──> make database request
request ──> make database request
request ──> make database request
database request complete ──> send response
database request complete ──> send response
database request complete ──> send response

실제로 두 접근 방식 모두 처리를 지배하는 것은 데이터베이스 응답 시간이기 때문에 거의 동일한 지연 시간으로 데이터를 반환합니다.

여기서 가장 큰 장점은 우리가 새로운 실을 생산할 필요가 없기 때문에 우리의 속도를 늦출 수 있는 많은 말록을 할 필요가 없다는 것입니다.

마법, 보이지 않는 스레드

겉보기에 불가사의한 것은 위의 두 가지 접근 방식이 어떻게 "병렬"로 워크로드를 실행할 수 있는가 하는 점입니다.정답은 데이터베이스가 스레드화되어 있다는 것입니다.단일 스레드 애플리케이션은 데이터베이스라는 다른 프로세스의 멀티 스레드 동작을 활용합니다.

단일 스레드 접근 방식이 실패하는 경우

데이터를 반환하기 전에 많은 CPU 계산을 수행해야 하는 경우 단일 스레드 앱이 크게 실패합니다.데이터베이스 결과를 루프 처리하는 것을 의미하는 것은 아닙니다.그것은 여전히 대부분 O(n)입니다.제가 의미하는 것은 푸리에 변환(예: mp3 인코딩), 광선 추적(3D 렌더링) 등을 수행하는 것입니다.

단일 스레드 애플리케이션의 또 다른 함정은 단일 CPU 코어만 사용한다는 것입니다.따라서 쿼드코어 서버(현재는 드물지 않음)가 있으면 나머지 3개의 코어를 사용하지 않습니다.

멀티스레드 방식이 실패하는 경우

스레드당 많은 RAM을 할당해야 하는 경우 멀티스레드 애플리케이션이 크게 실패합니다.첫째, RAM 사용량 자체는 단일 스레드 앱만큼 많은 요청을 처리할 수 없음을 의미합니다.더 나쁜 것은 말록이 느리다는 것입니다.많은 개체(현대 웹 프레임워크에서 일반적으로 사용되는)를 할당하는 것은 단일 스레드 앱보다 잠재적으로 느릴 수 있음을 의미합니다.여기서 보통 node.js가 승리합니다.

멀티스레드를 더 나쁘게 만드는 한 가지 사용 사례는 스레드에서 다른 스크립트 언어를 실행해야 하는 경우입니다.먼저 일반적으로 해당 언어의 전체 런타임을 malloc한 다음 스크립트에서 사용하는 변수를 malloc해야 합니다.

따라서 네트워크 앱을 C, go 또는 java로 작성하는 경우 스레드화의 오버헤드는 일반적으로 그리 나쁘지 않을 것입니다.만약 당신이 PHP나 Ruby를 제공하기 위해 C 웹 서버를 작성하고 있다면 자바스크립트나 Ruby 또는 Python으로 더 빠른 서버를 작성하는 것은 매우 쉽습니다.

하이브리드 접근법

일부 웹 서버는 하이브리드 방식을 사용합니다.예를 들어 Nginx 및 Apache2는 네트워크 처리 코드를 이벤트 루프의 스레드 풀로 구현합니다.각 스레드는 요청을 단일 스레드로 처리하는 이벤트 루프를 동시에 실행하지만 요청은 여러 스레드 간에 로드 밸런싱됩니다.

일부 단일 스레드 아키텍처도 하이브리드 방식을 사용합니다.단일 프로세스에서 여러 스레드를 실행하는 대신 쿼드코어 시스템에서 4개의 node.js 서버와 같은 여러 애플리케이션을 실행할 수 있습니다.그런 다음 로드 밸런서를 사용하여 프로세스 간에 워크로드를 분산합니다.node.js의 클러스터 모듈은 정확히 이 작업을 수행합니다.

사실상 두 접근 방식은 기술적으로 서로 동일한 미러 이미지입니다.

당신이 생각하는 것처럼 보이는 것은 대부분의 처리가 노드 이벤트 루프에서 처리된다는 것입니다.노드는 실제로 I/O 작업을 스레드로 파밍합니다.I/O 작업은 일반적으로 CPU 작업보다 훨씬 오래 걸립니다. 그런데 왜 CPU가 이 작업을 기다립니까?게다가 OS는 이미 I/O 작업을 매우 잘 처리할 수 있습니다.실제로 노드는 대기 시간이 없기 때문에 CPU 활용률이 훨씬 높습니다.

비유하자면, NodeJS를 I/O 셰프가 주방에서 고객의 주문을 준비하는 동안 웨이터로 생각해 보십시오.다른 시스템에서는 여러 명의 요리사가 고객의 주문을 받고, 식사를 준비하고, 식탁을 치우고, 다음 고객을 응대합니다.

단일 스레드 이벤트 루프 모델 처리 단계:

• 클라이언트 웹 서버로 요청을 보냅니다.

• 노드 JS 웹 서버는 클라이언트 요청에 서비스를 제공하기 위해 내부적으로 제한된 스레드 풀을 유지합니다.

• 노드 JS 웹 서버는 이러한 요청을 수신하여 대기열에 넣습니다.이벤트 대기열이라고 합니다."라고 합니다.

• 노드 JS 웹 서버에는 내부적으로 "이벤트 루프"라고 하는 구성 요소가 있습니다.이 이름을 갖게 된 이유는 무한 루프를 사용하여 요청을 수신하고 처리하기 때문입니다.

• 이벤트 루프는 단일 스레드만 사용합니다.Node JS 플랫폼 처리 모델의 주요 핵심입니다.

• 이벤트 루프는 클라이언트 요청이 이벤트 대기열에 있는지 확인합니다.그렇지 않은 경우 수신 요청을 무기한 기다립니다.

• 가능한 경우 이벤트 대기열에서 클라이언트 요청 하나 선택

  1. 클라이언트가 요청하는 프로세스를 시작합니다.
  2. 클라이언트 요청에 차단 IO 작업이 필요하지 않으면 모든 작업을 처리하고 응답을 준비한 후 클라이언트로 다시 보냅니다.
  3. 해당 클라이언트 요청에 데이터베이스, 파일 시스템, 외부 서비스와의 상호 작용과 같은 일부 차단 IO 작업이 필요한 경우에는 다른 접근 방식을 따릅니다.
• 내부 스레드 풀에서 스레드 가용성 확인
• 하나의 스레드를 선택하고 이 클라이언트 요청을 해당 스레드에 할당합니다.

• 해당 스레드는 해당 요청을 받아 처리하고, 차단 IO 작업을 수행하고, 응답을 준비한 후 이벤트 루프로 다시 전송합니다.

  더 많은 설명을 위해 @Rambabu Posa에 의해 매우 잘 설명되었습니다. 이 링크를 던져보세요.

Node.js는 단일 스레드와 이벤트 루프를 사용하여 요청을 한 번에 하나만 처리하는 것으로 알고 있습니다(이는 비차단).

여기서 말씀하신 내용을 오해하고 있을 수도 있지만, "한 번에 하나씩"은 이벤트 기반 아키텍처를 완전히 이해하지 못하는 것처럼 들립니다.

"기존"(이벤트 중심이 아닌) 애플리케이션 아키텍처에서 프로세스는 무언가가 발생하기를 기다리는 데 많은 시간을 소비합니다.Node.js와 같은 이벤트 기반 아키텍처에서는 프로세스가 대기만 하는 것이 아니라 다른 작업을 계속할 수 있습니다.

예를 들어, 클라이언트로부터 연결을 받고, 이를 수락하고, 요청 헤더를 읽은 다음(http의 경우), 요청에 대한 작업을 시작합니다.요청 본문을 읽을 수도 있고, 일반적으로 일부 데이터를 클라이언트에 다시 전송하게 됩니다(이것은 요점을 설명하기 위해 의도적으로 절차를 간소화한 것입니다).

이러한 각 단계에서 대부분의 시간은 다른 쪽 끝에서 일부 데이터가 도착하기를 기다리는 데 사용됩니다. 일반적으로 주 JS 스레드에서 처리하는 데 소요되는 실제 시간은 매우 미미합니다.

I/O 개체(예: 네트워크 연결)의 상태가 변경되어 처리가 필요한 경우(예: 소켓에서 데이터 수신, 소켓 쓰기 가능 등) 메인 Node.js JS 스레드가 처리해야 하는 항목 목록과 함께 웨이크업됩니다.

관련 데이터 구조를 찾아 해당 구조에서 콜백을 실행하거나 수신 데이터를 처리하거나 소켓에 더 많은 데이터를 쓰는 이벤트를 발생시킵니다.처리가 필요한 모든 I/O 개체가 처리되면 기본 Node.js JS 스레드는 더 많은 데이터를 사용할 수 있다는 메시지가 표시될 때까지(또는 일부 다른 작업이 완료되거나 시간 초과됨) 다시 대기합니다.

다음 번에 깨울 때는 처리해야 하는 다른 I/O 개체(예: 다른 네트워크 연결) 때문일 수 있습니다.매번 관련 콜백이 실행된 다음 다른 일이 발생할 때까지 대기하면서 다시 절전 모드로 전환됩니다.

중요한 점은 서로 다른 요청의 처리가 인터리브된다는 것입니다. 처음부터 끝까지 하나의 요청을 처리한 다음 다음으로 이동하지 않습니다.

제 생각에, 이것의 주된 장점은 느린 요청(예: 2G 데이터 연결을 통해 1MB의 응답 데이터를 휴대폰 장치로 보내려고 하거나 정말 느린 데이터베이스 쿼리를 수행하는 경우)이 더 빠른 요청을 차단하지 않는다는 것입니다.

일반적인 다중 스레드 웹 서버에서는 일반적으로 처리 중인 각 요청에 대한 스레드가 있으며, 요청이 완료될 때까지 해당 요청만 처리합니다.느린 요청이 많으면 어떻게 됩니까?많은 스레드가 이러한 요청을 처리하는 데 사용되고, 다른 요청(매우 간단한 요청일 수 있음)이 요청 뒤에 대기하게 됩니다.

Node.js 외에도 이벤트 기반 시스템이 많이 있으며, 기존 모델과 비교하여 장단점이 유사한 경향이 있습니다.

이벤트 기반 시스템이 모든 상황 또는 모든 워크로드에서 더 빠르다고는 할 수 없습니다. I/O 바인딩된 워크로드에서는 잘 작동하지만 CPU 바인딩된 워크로드에서는 잘 작동하지 않습니다.

답변에 하기: slebetman 답변가추: 이 고말할라고 말할 때.Node.JS 요청인 할 수 쿼리와 이 있습니다. 10,000개의 요청은 다음과 같습니다. 이는 기본적으로 데이터베이스 쿼리와 관련이 없는 요청입니다.

내적으로.event loopNode.JS는 처리중다니를 .thread pool서 각 는 각스드처는위치리하를 합니다.non-blocking request는 중 한 후 계속 더 합니다.thread pool스레드 중 하나가 작업을 완료하면, 그것은 신호를 전송합니다.event loop그것이 끝났다는 것.callback.Event loop그런 다음 이 콜백을 처리하고 응답을 다시 보냅니다.

은 노드에 .JS를 처음 사용하는 고객은 다음에 대해 자세히 알아보십시오.nextTick이벤트 루프가 내부적으로 어떻게 작동하는지 이해합니다.http://javascriptissexy.com 의 블로그를 읽어 보십시오. JavaScript/NodeJS를 시작했을 때 많은 도움이 되었습니다.

멀티 스레드 차단 시스템의 차단 부분으로 인해 효율성이 떨어집니다.차단된 스레드는 응답을 기다리는 동안 다른 용도로 사용할 수 없습니다.

비차단 단일 스레드 시스템은 단일 스레드 시스템을 최대한 활용합니다.

아래 다이어그램 참조: 고객이 음식을 고르는 동안 주방 문 앞에서 기다리거나 기다리는 것은 웨이터의 전체 용량을 "차단"하는 것입니다.컴퓨팅 시스템의 경우, 스레드가 대기 중에 다른 작업을 수행할 수 있더라도 IO 또는 DB 응답을 대기하거나 전체 스레드를 차단하는 모든 작업을 대기할 수 있습니다.

비차단의 작동 방식을 살펴보겠습니다.

비차단 시스템에서 웨이터는 주문과 서빙만 받고, 아무데서나 기다리지 않습니다.그는 주문이 완료되면 전화를 다시 걸 수 있도록 휴대전화 번호를 공유합니다.마찬가지로, 그는 주문이 제공될 준비가 되면 전화를 걸기 위해 주방과 자신의 번호를 공유합니다.

이것이 이벤트 루프가 NodeJS에서 작동하는 방식이며 멀티스레드 시스템을 차단하는 것보다 더 나은 성능을 발휘합니다.

코드를 실행하는 동안 발생하는 일에 대한 더 명확한 설명을 위해 slebetman의 답변에 추가합니다.

nodeJs의 내부 스레드 풀에는 기본적으로 4개의 스레드만 있습니다. 그리고 전체 요청이 스레드 풀의 새 스레드에 연결되는 것이 아니라 요청의 전체 실행이 일반적인 요청처럼 발생합니다(차단 작업 없이). 단지 요청이 오래 실행되거나 dbcall과 같은 무거운 작업이 있을 때마다,파일 작업 또는 http 요청이 libuv에 의해 제공되는 내부 스레드 풀에 대기합니다.또한 nodeJs는 내부 스레드 풀에서 기본적으로 4개의 스레드를 제공하므로 5번째 또는 다음 동시 요청 시마다 스레드가 사용 가능해질 때까지 대기하고 이러한 작업이 끝나면 콜백 대기열로 푸시됩니다.이벤트 루프에 의해 선택되고 응답을 다시 보냅니다.

여기서 한 번의 콜백 대기열이 아니라 많은 대기열이 있다는 또 다른 정보가 있습니다.

1. NextTick 대기열
2. 마이크로 태스크 대기열
3. 타이머 큐
4. IO 콜백 대기열(요청, 파일 작업, dops)
5. IO 폴 대기열
6. 단계 대기열 선택 또는 즉시 설정
7. 처리기 대기열 닫기

요청이 올 때마다 코드는 대기 중인 콜백 순서대로 실행됩니다.

차단 요청이 있을 때는 새 스레드에 연결되지 않습니다.기본적으로 4개의 스레드만 있습니다.그래서 그곳에서 또 다른 대기 행렬이 일어나고 있습니다.

코드에서 파일 읽기와 같은 차단 프로세스가 발생할 때마다 스레드 풀의 스레드를 사용하는 함수를 호출한 다음 작업이 완료되면 콜백이 해당 대기열로 전달되고 순서대로 실행됩니다.

모든 항목은 콜백 유형에 따라 대기열에 저장되고 위에서 언급한 순서대로 처리됩니다.

다음은 이 매체 기사의 좋은 설명입니다.

NodeJS 응용 프로그램을 지정할 경우, 노드는 단일 스레드이므로 처리에 Promise가 포함되는지 여부를 지정합니다.8초가 걸리는 모든 것, 이것은 이 요청 이후에 오는 클라이언트 요청이 8초 동안 기다려야 한다는 것을 의미합니까?NodeJS 이벤트 루프는 단일 스레드입니다.노드에 대한 전체 서버 아키텍처JS는 단일 나사산이 아닙니다.

노드 서버 아키텍처에 들어가기 전에 일반적인 멀티스레드 요청 응답 모델을 살펴보기 위해 웹 서버는 여러 스레드를 가지고 있으며 동시 요청이 웹 서버에 도달할 수 있습니다.웹 서버는 threadPool 및 threadOne에서 threadOne을 선택합니다. 하나는 requestOne을 처리하고 clientOne에 응답합니다. 두 번째 요청이 들어오면 웹 서버는 threadPool에서 두 번째 스레드를 선택하여 requestTwo를 처리하고 clientTwo에 응답합니다.스레드원은 차단 IO 작업을 포함하여 요청한 모든 종류의 작업을 담당합니다.

스레드가 IO 작업을 차단하기 위해 기다려야 한다는 사실이 비효율적인 이유입니다.이런 종류의 모델을 사용하면 웹 서버는 스레드 풀에 있는 스레드 수만큼의 요청만 처리할 수 있습니다.

NodeJS 웹 서버는 제한된 스레드 풀을 유지 관리하여 클라이언트 요청에 서비스를 제공합니다.여러 클라이언트가 노드에 여러 번 요청합니다.JS 서버.NodeJS는 이러한 요청을 수신하여 EventQueue에 배치합니다.NodeJS 서버에는 요청을 수신하고 처리하는 무한 루프인 EventLoop이라고 하는 내부 구성 요소가 있습니다.이 이벤트 루프는 단일 스레드입니다.즉, EventLoop은 EventQueue의 수신기입니다.따라서 요청이 배치되는 이벤트 대기열과 이벤트 대기열에서 이러한 요청을 청취하는 이벤트 루프가 있습니다.그다음엔 무슨일이일어날까?수신기(이벤트 루프)는 요청을 처리하며, 차단 IO 작업 없이 요청을 처리할 수 있으면 이벤트 루프가 자체적으로 요청을 처리하고 응답을 클라이언트로 다시 보냅니다.현재 요청이 차단 IO 작업을 사용하는 경우 이벤트 루프는 스레드 풀에 사용 가능한 스레드가 있는지 확인하고 스레드 풀에서 하나의 스레드를 선택한 스레드에 특정 요청을 할당합니다.이 스레드는 차단 IO 작업을 수행하고 응답을 이벤트 루프로 다시 보내고 응답이 이벤트 루프에 도달하면 이벤트 루프가 응답을 클라이언트로 다시 보냅니다.

NodeJS가 기존의 멀티스레드 요청 응답 모델보다 어떻게 더 낫습니까?기존의 멀티스레드 요청/응답 모델에서는 모든 클라이언트가 서로 다른 스레드를 얻지만 NodeJS와 마찬가지로 단순한 요청은 모두 EventLoop에서 직접 처리됩니다.이것은 스레드 풀 리소스의 최적화이며 모든 클라이언트 요청에 대해 스레드를 생성하는 오버헤드가 없습니다.

node.js에서 요청은 CPU 바인딩이 아닌 IO 바인딩이어야 합니다.각각의 요청이 node.js에게 많은 계산을 강요해서는 안 된다는 것을 의미합니다.요청 해결과 관련된 계산이 많은 경우 node.js는 좋은 선택이 아닙니다.IO 바인딩은 거의 필요하지 않습니다. 요청하는 대부분의 시간은 DB 또는 서비스에 호출하는 데 사용됩니다.

Node.js는 싱글스레드 이벤트 루프를 가지고 있지만 셰프일 뿐입니다.대부분의 작업은 운영 체제에서 수행되며 Libuv는 운영 체제와의 통신을 보장합니다.Libuv 문서에서:

이벤트 중심 프로그래밍에서 응용 프로그램은 특정 이벤트에 대한 관심을 표현하고 이벤트가 발생할 때 응답합니다.운영 체제에서 이벤트를 수집하거나 다른 이벤트 소스를 모니터링하는 책임은 libuv에서 처리하며, 사용자는 이벤트 발생 시 호출할 콜백을 등록할 수 있습니다.

들어오는 요청은 운영 체제에서 처리합니다.이것은 요청-응답 모델에 기반한 거의 모든 서버에 대해 거의 정확합니다.수신 네트워크 호출은 OS 비차단 IO 대기열에 대기됩니다.'Event LoopOS IO 대기열을 지속적으로 폴링하여 수신 클라이언트 요청을 파악합니다."폴링"은 특정 리소스의 상태를 정기적으로 확인하는 것을 의미합니다.요청이 요청을 요청을 합니다.synchronously비동기 호출이 있는 경우(즉, setTimeout) 실행하는 동안 콜백 대기열에 들어갑니다.이벤트 루프는 동기화 호출 실행을 마친 후 콜백을 폴링할 수 있으며, 실행해야 하는 콜백을 찾으면 해당 콜백을 실행합니다.수신 요청에 대한 폴링을 수행합니다.node.js 문서를 확인하면 다음 이미지가 있습니다.

문서 단계 개요

poll: 새 I/O 이벤트 검색, I/O 관련 콜백 실행(거의 모든 콜백 닫기, 타이머에 의해 예약된 콜백 및 setImediate() 제외), 노드가 적절한 경우 여기서 차단됩니다.

따라서 이벤트 루프는 서로 다른 큐에서 지속적으로 폴링됩니다.외부 호출 또는 디스크 액세스에 대한 요청이 필요한 경우, 이 요청은 OS로 전달되며 OS에도 이를 위한 두 개의 다른 대기열이 있습니다.하자마자event loop비동기식으로 수행해야 하는 작업을 감지하면 대기열에 넣습니다.대기열에 넣으면 이벤트 루프가 다음 작업으로 진행됩니다.

여기서 언급해야 할 한 가지는 이벤트 루프가 지속적으로 실행된다는 것입니다.CPU만 이 스레드를 CPU 밖으로 이동할 수 있으며 이벤트 루프 자체는 이를 수행하지 않습니다.

문서에서:

Node.js의 확장성의 비밀은 적은 수의 스레드를 사용하여 많은 클라이언트를 처리한다는 것입니다.Node.js가 더 적은 스레드로 해결할 수 있는 경우, 스레드에 대한 공간 및 시간 오버헤드(메모리, 컨텍스트 전환)를 지불하는 것보다 시스템의 시간과 메모리를 클라이언트 작업에 더 많이 사용할 수 있습니다.그러나 Node.js에는 스레드가 몇 개밖에 없기 때문에 스레드를 현명하게 사용하도록 응용프로그램을 구성해야 합니다.

Node.js 서버의 속도를 유지하기 위한 경험칙은 다음과 같습니다.Node.js는 주어진 시간에 각 클라이언트와 관련된 작업이 "작을" 때 빠릅니다.

작은 작업은 CPU가 아닌 IO 바인딩된 작업을 의미합니다.싱글event loop각 요청에 대한 작업이 대부분 IO 작업인 경우에만 클라이언트 로드를 처리합니다.

Context switch기본적으로 CPU 리소스가 부족하므로 다른 프로세스가 실행되도록 하려면 한 프로세스의 실행을 중지해야 합니다.OS는 먼저 프로세스 1을 제거해야 하므로 CPU에서 이 프로세스를 가져와 메인 메모리에 저장합니다.다음으로 OS는 프로세스 제어 블록을 메모리에서 로드하여 프로세스 2를 복원하고 실행을 위해 CPU에 배치합니다.그러면 process2가 실행을 시작합니다.프로세스 1이 종료되고 프로세스 2가 시작되는 사이에 시간이 좀 걸렸습니다.스레드 수가 많으면 로드가 많은 시스템이 스레드 스케줄링 및 컨텍스트 전환에 귀중한 주기를 소비하게 되므로 지연 시간이 추가되고 확장성 및 처리량에 제한이 가해질 수 있습니다.

언급URL : https://stackoverflow.com/questions/34855352/how-in-general-does-node-js-handle-10-000-concurrent-requests