미래 지향적인 웹 앱 구축: The Codest의 전문가 팀이 제공하는 인사이트
The Codest가 최첨단 기술로 확장 가능한 대화형 웹 애플리케이션을 제작하고 모든 플랫폼에서 원활한 사용자 경험을 제공하는 데 탁월한 성능을 발휘하는 방법을 알아보세요. Adobe의 전문성이 어떻게 디지털 혁신과 비즈니스를 촉진하는지 알아보세요...
"이벤트 루프를 차단하지 마세요..." - 아마 이 문장을 여러 번 들어보셨을 겁니다... 노드로 작업할 때 가장 중요한 가정 중 하나이기 때문에 놀랍지 않습니다. 그러나 차단하지 말아야 할 두 번째 '것'이 있는데, 바로 워커 풀입니다. 이를 무시하면 애플리케이션 성능과 보안에 심각한 영향을 미칠 수 있습니다.
기억해야 할 주요 사항: 다음 두 가지 유형의 스레드가 있습니다. Node.js: 메인 스레드 - 다음에서 처리합니다. 이벤트 루프및 작업자 풀 (스레드 풀) - 스레드 풀입니다.
리부브 덕분에. 각각 다른 작업을 수행합니다. 첫 번째는 비차단 I/O 작업을 처리하는 것이고, 두 번째는 CPU 집약적인 작업과 차단 I/O를 담당합니다.
그렇다면 스레드란 무엇이며 프로세스와는 어떻게 다를까요? 몇 가지 차이점이 있지만 가장 중요한 차이점은 메모리가 할당되는 방식입니다. 프로세스는 애플리케이션과 비슷하다고 생각하면 됩니다. 각 프로세스 안에는 이 프로세스만을 위한 메모리 덩어리가 있습니다. 따라서 한 프로세스는 다른 프로세스의 메모리에 액세스할 수 없으며, 이 속성은 높은 보안을 보장합니다. 이들 간의 통신을 설정하려면 몇 가지 작업을 수행해야 합니다. 스레드는 다릅니다. 스레드는 프로세스 내부에서 실행되고 동일한 메모리를 공유하므로 스레드가 데이터를 공유하는 데 전혀 문제가 없습니다.
하지만 한 가지 문제가 발생합니다. 바로 경쟁 조건입니다. 스레드가 동시에 실행될 수 있는데 어느 것이 먼저 끝나는지 어떻게 알 수 있을까요? 처음 실행할 때는 첫 번째 작업이 먼저 끝나고 다음에는 그 반대로 두 번째 작업이 첫 번째 작업보다 먼저 끝나는 경우가 발생할 수 있습니다. 이러한 조건에서 쓰기/읽기 작업을 한다고 상상해 보세요! 악몽이 따로 없죠! 때로는 올바르게 쓰는 것이 매우 어렵습니다. 코드 를 멀티 스레드 환경에서 사용할 수 있습니다.
또한 멀티 스레드 언어는 각 요청마다 별도의 스레드를 생성하기 때문에 메모리 오버헤드가 크므로 1000개의 요청을 호출하려는 경우 1000개의 스레드를 생성합니다.
이러한 문제를 어떻게 처리할 수 있을까요? 대신 단일 스레드를 사용하세요! 이것이 바로 노드 를 제공합니다.
로서 JavaScript 개발자 다음 동영상을 시청해 보시기 바랍니다. 영화
에서 바트 벨더가 이벤트 루프의 개념을 명확하게 설명합니다. 위의 다이어그램은 그의 프레젠테이션에서 가져온 것입니다. 이 용어를 전혀 모르신다면 두 가지 모두 노드 와 Libuv는 훌륭한 문서를 보유하고 있습니다 🙂
In JavaScript 개발 업계에서는 다음과 같은 이유로 노드 는 단일 스레드 및 논-블록킹이므로 멀티 스레드 솔루션보다 동일한 리소스로 더 높은 동시성을 달성할 수 있습니다. 사실이지만 보기만큼 아름답고 쉽지는 않습니다.
이후 Node.js 가 단일 스레드(JS 부분)인 경우, CPU 집약적인 작업은 특정 작업이 완료될 때까지 진행 중인 모든 요청을 차단합니다. 따라서 Node.js 요청 중 하나에 차단 명령어가 포함되어 있다는 이유만으로 모든 요청을 차단할 수 있습니다. 차단 코드는 완료하는 데 몇 밀리초가 더 걸린다는 것을 의미합니다. 하지만 긴 응답 시간을 차단과 혼동하지 마세요. 데이터베이스의 응답은 매우 오랜 시간이 걸릴 수 있지만 프로세스(애플리케이션)를 차단하지는 않습니다.
차단 메서드는 동기적으로 실행되고 비차단 메서드는 비동기적으로 실행됩니다.
이벤트 루프 속도를 늦추거나 차단하려면 어떻게 해야 하나요?
이 경우 워커 풀은 스레드 풀을 사용하기 때문에 차단도 가능한가요? 불행히도, 네 🙁 노드 는 다음과 같은 철학을 기반으로 합니다. 하나의 스레드로 여러 클라이언트를 지원합니다.
특정 워커가 수행하는 특정 작업이 매우 복잡하고 완료하는 데 더 많은 시간이 필요하다고 가정해 봅시다. 결과적으로 해당 워커는 차단되고 해당 명령이 실행될 때까지 다른 보류 중인 작업을 실행하는 데 사용할 수 없게 됩니다. 이제 짐작하셨겠지만 성능에 영향을 미칠 수 있습니다. 작업 파티셔닝을 사용하여 작업 시간의 변화를 최소화하면 이러한 문제를 방지할 수 있습니다.
차단은 절대 피하세요. 가능하다면 항상 표준 라이브러리 API의 비동기 버전을 선택하세요. 그렇지 않으면 앱을 실행한 후 클라이언트는 처리량 저하부터 시작하여 완전한 탈퇴까지 여러 가지 문제를 경험할 수 있으며, 이는 사용자 입장에서 치명적입니다.
자세히 읽어보세요: