PHP (또는 Java / ASP.NET / Ruby) 기반 웹 서버에서 모든 클라이언트 요청은 새 스레드에서 인스턴스화됩니다. 그러나 Node.js에서 모든 클라이언트는 동일한 스레드에서 실행됩니다 (동일한 변수를 공유 할 수도 있습니다!) I / O 작업은 이벤트 기반이므로 기본 스레드 루프를 차단하지 않습니다.
내가 이해하지 못하는 것은 Node 작성자가 단일 스레드로 선택한 이유는 무엇입니까? 상황을 어렵게 만듭니다. 예를 들어, 메인 스레드를 차단하고 새로운 클라이언트 요청이 차단되므로 CPU 집약적 기능을 실행할 수 없으므로 프로세스를 생성해야합니다. 즉, 별도의 JavaScript 파일을 작성하고 다른 노드 프로세스를 실행해야합니다. 그것). 그러나 PHP에서 CPU 집중적 인 작업은 각 클라이언트가 다른 스레드에 있기 때문에 다른 클라이언트를 차단하지 않습니다. 멀티 스레드 웹 서버와 비교했을 때의 장점은 무엇입니까?
참고 :이 문제를 해결하기 위해 클러스터링을 사용했지만 그다지 좋지 않습니다.
답변
Node.js는 비동기 처리 실험으로 명시 적으로 작성되었습니다. 이론은 단일 스레드에서 비동기 처리를 수행하면 일반적인 스레드 기반 구현보다 일반적인 웹로드에서 더 많은 성능과 확장 성을 제공 할 수 있다는 것입니다.
그리고 당신은 무엇을 알고 있습니까? 제 생각에는 이론이 널리 퍼져 있다는 것입니다. CPU를 많이 사용하지 않는 node.js 앱은 Apache 또는 IIS 또는 다른 스레드 기반 서버보다 수천 개의 동시 연결을 실행할 수 있습니다.
단일 스레드, 비동기 특성으로 인해 작업이 복잡해집니다. 그러나 솔직히 스레딩보다 더 복잡하다고 생각하십니까? 한 번의 경쟁 조건으로 한 달 내내 망치질 수 있습니다! 또는 어딘가에 설정되어 스레드 풀을 비우고 응답 시간이 느려지는 것을 지켜보십시오! 교착 상태, 우선 순위 반전 및 멀티 스레딩과 함께 제공되는 다른 모든 설명은 말할 것도 없습니다.
결국, 그것이 보편적으로 더 나쁘다고 생각하지 않습니다. 그것은 다르고 때로는 더 좋으며 때로는 그렇지 않습니다. 작업에 적합한 도구를 사용하십시오.
답변
서버에 대한 “요청 당 하나의 스레드”모델의 문제점은 이벤트 루프 스레드 모델과 비교하여 여러 시나리오에서 확장 성이 좋지 않다는 것입니다.
일반적으로 I / O 집중 시나리오에서는 요청이 I / O가 완료 될 때까지 대부분의 시간을 소비합니다. 이 시간 동안 “요청 당 하나의 스레드”모델에서 스레드에 연결된 리소스 (예 : 메모리)는 사용되지 않으며 메모리가 제한 요소입니다. 이벤트 루프 모델에서 루프 스레드는 처리 할 다음 이벤트 (I / O 완료)를 선택합니다. 따라서 스레드는 항상 사용 중입니다 (물론 올바르게 프로그래밍하면).
모든 새로운 것의 이벤트 루프 모델은 빛나고 모든 문제에 대한 솔루션이지만 사용할 모델은 해결해야 할 시나리오에 따라 다릅니다. 프록시와 같은 집중적 인 I / O 시나리오가있는 경우, 이벤트 기반 모델이 지배하는 반면 동시 프로세스 수가 적은 CPU 집중 시나리오는 스레드 기반 모델에서 가장 잘 작동합니다.
현실 세계에서 대부분의 시나리오는 약간 중간에 있습니다. 정확한 아키텍처를 찾으려면 확장성에 대한 실제 요구와 개발 복잡성의 균형을 맞출 필요가 있습니다 (예 : CPU 집약적 작업을 위해 백엔드에 위임하는 이벤트 기본 프런트 엔드를 갖습니다. 프런트 엔드는 작업을 기다리는 데 거의 리소스를 사용하지 않습니다. 분산 시스템과 마찬가지로 작동하려면 약간의 노력이 필요합니다.
아무 노력없이 시나리오에 맞는 은색 총알을 찾고 있다면 발에 총알이 생깁니다.
답변
간단히 말해 노드는 V8에서 가져옵니다. V8은 내부적으로 단일 스레드입니다. CPU를 많이 사용하는 작업의 제약 조건을 해결하는 방법이 있습니다.
한 시점 (0.7)에서 저자는 여러 계산 스레드를 구현하는 방법으로 분리를 도입하려고 시도했지만 결국 제거되었습니다. https://groups.google.com/forum/#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ
