기본 콘텐츠로 건너뛰기

Node.js 웹 서버가 JAVA 웹 서버보다 성능이 뛰어날까?

Node.js 웹 서버가 JAVA 웹 서버보다 성능이 뛰어날까?


Node.js 웹 서버가 JAVA 웹 서버보다 성능이 뛰어나다는 소문에 대한 진실을 파해쳐겠다. 이 글에서는 해당 소문을 재시하는 다양한 사람들의 근거와 진실 여부를 파악하여 결론을 도출하겠다.



1. 많은 사람들이 그 이유를 제대로 설명하지 못한다.


아래는 여러 블로그 글들을 읽어보고 가장 많이 사람들이 근거로 드는 내용을 정리 한 것이다.

Node.js는 싱글 쓰레드 기반의 논블로킹 방식의 I/O를 사용하고, 멀티 쓰레드와 블로킹 방식 I/O를 사용하는 자바 웹 서버보다 빠르다. 왜냐하면 멀티 쓰레드 방식은 컨텍스트 스위치 오버헤드가 있기 때문이다???


정말 어이없다. 이는 더 성능이 빠른 이유가 될수 없고, 그나마 싱글 쓰레드 기반인 Node.js가 멀티 쓰레드 기반인 자바 웹 서버 처럼 여러 요청에 대한 동시적인 처리를 할 수 있는 이유가 될 뿐, 이 사실 자체로는 더 나은 성능을 나타내는 이유가 될 수는 없다. 생각해보라, 논블로킹 방식의 I/O를 지원하는 것도 결국 Node.js가 내부적으로 멀티 쓰레드를 구현하고 있다라는 의미 밖에 안되고, 이도 마찬가지로 자체적인 컨텍스트스위칭이 필요할 것이다. 즉, 단순히 논블로킹 싱글 쓰레드라서 블로킹 멀티 쓰레드보다 빠르다는건 논리적으로 근거가 빈약하다



2. 내가 여러 기술 스펙들을 읽어보고 정리해 보았다


개인적인 주장이니 어디가서 정답인양 말하지 말라.

2.1. NodeJS가 비동기 I/O 시스템 콜의 활용성이 더 좋다.


본래 태초에 OS가 등장 했을 때는 I/O 시스템 콜[1]은 동기 요청 방식만 제공하였었다. 프로그램은 I/O요청에 대한 비동기적인 처리를 위해 별도의 쓰래드를 생성하는 것이 일반적이 었다. 그리고 이러한 비동기 방식의 사용자 I/O 요청이 보편화 되자 이를 표준화한 POSIX 1.b의 AIO도 등장하여 이를 따르는 많은 OS들에서 더욱 쉽게 비동기 I/O 요청을 사용할 수 있게 되었다. 물론 오직 API 규격으로써 당시에 그 내부적인 구현이 있지도 않은 비동기 I/O 시스템 콜을 이용한다는 말은 아니다.

태초의 OS는 동기 방식의 I/O 시스템 콜만을 지원. 사용자 레벨의 쓰레드와 동기 I/O 시스템 콜을 활용하여 사용자 레벨의 비동기 I/O를 구현.

[1] 여기서 말하는 시스템 콜은 POSIX 시스템 콜이 아니다.(시스템 콜에 대한 POSIX 규격 인터페이스를 POSIX 시스템 콜이라고 부르기도 한다)


그러나 얼마전부터 자체적으로 비동기 I/O 시스템 콜을 지원해 주는 OS들이 등장하기 시작했다. 대표적으로 linux AIO(kernel ver 2.6부터 표준)을 들수가 있다. 이들은 모두 커널 레벨의 비동기 I/O 요청을 구현함으로서 커널에서 내부적으로 비동기 처리에 쓰일 쓰레드를 생성 관리하기 때문에 성능이 아주 우수하다. 물론 그 구현과 지원 여부는 OS마다 다른데, Node.js는 구동 OS의 지원 여부에 따라 이러한 커널 수준의 비동기 I/O를 사용한다. 그렇다면, JAVA는 커널 수준의 비동기 I/O를 사용하지 않는가? 아니다. JAVA도 OS 커널의 비동기 I/O 시스템 콜을 사용하는 java.nio 가 마련되어 있다. JAVA 1.4 때 등장해서 웹 서버에 사용되기 시작했는데, Tomcat에서는 NIO Connector를 통해 소켓 연결할 때 사용한다. NIO Connector 같은 경우 Tomcat 6.0때 등장해서 8.0부터는 개선된 java.nio2를 사용하는 기본 Connector가 되었으니, Tomcat 8.0부터 본격적으로 커널 레벨의 비동기 I/O를 사용하기 시작했다고 할 수 있다. 이후 9.0부터는 블로킹(동기)방식의 BIO Connector는 아예 사라졌다고 한다. 톰켓 8.0 나온 시점보다 한참 전인 2009년에 Node.js가 나왔으니, 적어도 그 기간 동안에는 Node.js의 비동기 I/O 성능이 압도적이었다고 할 수 있다.

각종 OS에 비동기 I/O 시스템 콜의 등장하고 이를 활용하는 Node.js가 등장했다. 이는 비동기 I/O에 있어서 기존의 동기방식 I/O 시스템 콜과 멀티 쓰레드를 활용하는 자바 웹 서버보다 성능이 뛰어났다.


2.2. Node.js 웹 서버는 보다 I/O 집약적인 Thread Pool을 가진다


Tomcat 8.0이후 시점으로 봤을 때도, 여전히 Node.js의 비동기 I/O속도가 빠른가? 라는 의문이 생기는데, 이 부분에서도 Yes라고 할 수 있다. 우선 Node.js에서는 기본적으로 Network I/O를 이벤트 루프에서 Polling 메커니즘[1]을 통해 처리한다.[2] Node.js는 Polling을 통한 Single Thread Non-Blocking Network I/O 방식을 OS와 무관하게 제공한다. 이를 위해 Node.js가 각 OS에서 사용하는 기술들은 다음과 같다.

  • linux : epoll
  • OSX, BSDs : kqueue
  • SunOS, windows : event ports

* 자세한 내용은 libuv 공식 홈페이지에서 확인할 수 있다.

Network I/O를 제외하고도 프로그램이 정상적으로 구동되기 위해 반드시 비동기로 처리해야할 것들은 크게 2종류가 있다. Network를 제외한 I/O-Intensive 작업과 CPU-Intensive 작업들이다. 이 둘은 긴 처리시간으로 프로그램의 흐름을 막을 것이다. Node.js는 OS에서 제공하는 비동기 시스템 콜을 우선적으로 활용하면서 제공되지 않는 요청에 대해서는 자체적인 Thread Pool인 Worker Pool에 작업을 할당해 처리한다. 그런데 여기서 중요한 점은, Node.js는 오로지 웹 서버의 수행에 필수적인 작업에 한해 Worker Pool에 할당된 API를 제공한다는 점이다. 따라서, CPU-Intensive 작업들은 극히 일부의 필수 항목만이 기본적으로 Worker Pool에 할당되어진다.[3] 다음은 대부분의 경우 Worker List에서 수행되어지는 작업 목록이다.

  • I/O-Intensive
    1. DNS: dns.lookup(), dns.lookupService().
    2. File System: fs.FSWatcher()와 libuv의 스레드 풀을 명백하게 동기적으로 사용하는 경우를 제외한 모든 파일 시스템 API.[4]
  • CPU-Intensive
    1. Crypto: crypto.pbkdf2(), crypto.scrypt(), crypto.randomBytes(), crypto.randomFill(), crypto.generateKeyPair().
    2. Zlib: libuv의 스레드 풀을 명백하게 동기적으로 사용하는 경우를 제외한 모든 zlib API.

* 자세한 내용은 Node.js Doc를 참조.

따라서, Node.js는 Thread Pool의 상당부분을 비동기 시스템 콜 미지원 I/O-Intensive 작업의 처리에 사용한다는 점이다. 이는 기본적으로 각 Connection에 대해 Thread를 생성하고 사용자 코드를 포함한 모든 CPU-Intensive를 각 Thread에서 처리하는 대부분의 JAVA 웹 서버에 비해 I/O-Intensive 작업의 응답속도가 빨라질 수 밖에 없다. Node.js는 사용자 코드가 야기하는 CPU-Intensive 작업의 스케줄링을 포기하고 대신 I/O-Intensive 작업의 추가적인 할당을 선택했기 때문이다. Worker Pool 또는 커널을 통해 수행될 수 없는 작업은 모두 이벤트 루프에서 수행되기 때문에 이벤트 루프를 사용자가 작성한 CPU-Intensive한 코드로 막지 말아야 한다.[5] 복잡한 연산이 요구되는 사용자 코드의 작성은 Node.js의 설계 방향성과 맞지 않기에 그 장점을 살리지 못한다.

Node.js는 I/O 특화 Thread Pool을 가진다, Thread Pool 자원은 일부 필수 CPU-Intensive 작업을 제외하고 모두 I/O-Intensive 작업에게 할당되어진다. 정리하자면, 필수가 아닌 CPU-Inensive 작업들의 평균 응답속도를 포기해서 I/O-Intensive 작업의 평균 응답속도를 높혔다.


[1] Polling은 Socket이나 Pipe에서 사용될 수 있는 다중 입출력 방식으로, 여러 FD들을 모니터링하다가 특정 FD에 읽기/쓰기가 가능한 상태가 되었을 때 데이터가 해당 FD에 읽고 쓰는 방식으로, 예를 들어 읽을 데이터가 없는 FD에 대한 Blocking이나 현재 쓸수 없는 상태인 fd에 대한 Blocking을 발생시지 않기 때문에 다중 네트워크 입력을 Single Thread Non-blocking I/O 방식으로 처리할 수 있게 한다.
[2] 이벤트 루프를 I/O 루프라고도 부른다.
[3] 사용자 코드에서 API에서 제공하지 않는 자신만의 I/O-Intensive 요청을 작성할 일이 없지만, CPU-Intensive 코드는 비즈니스 로직에 따라, 기타 사용자 의도에 따라 그 종류가 무한하므로 사용자가 사용할 수 있는 모든 CPU-Intensive를 API로 제공하기는 것은 불가능 하다.
[4] 사실 여기서 더 자세히 들어가면, 커널 레벨의 비동기 시스템 콜이 없다고 해서 무조건 Worker Pool로 관리 되는 것도 아니다. OS 편차에 따라 다음과 같은 API를 사용한다고 한다.

  • linux AIO (supported in kernel)
  • posix AIO (supported by linux, BSD, Mac OS X, solaris, AIX, et)
  • Windows'overlapped I/O
 [5] Node.js공식 문서에서는 이벤트 루프에 수행될 이벤트 콜백에 시간 복잡도가 높은 연산을 포함시켜 서버 전체의 평균 응답시간으로 늘리는 것을 "막는다"라고 표현했다.
라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

Cubase : Serum 사용법(1) : 소개와 오실레이터, 필터, 모듈레이터의 사용법

큐베이스 가상악기 Serum 사용법(1) Serum 소개와 오실레이터, 필터, 모듈레이터의 사용법 1. Serum 이란? 큐베이스에서 사용가능한 가상악기 VST 플러그인 형태로 나온 Software Synthesizer 이다. 사운드의 시각화가 잘 되어있는게 특징이며, 웨이브테이블을 통해 다체로운 사운드를 만들 수 있는게 특징이다. Serum 사용 화면. 2. Serum 의 구조 소프트웨어 신디사이저는 구조는 다음과 같고 Serum도 이러한 구조로 이루어져있다. 신디사이저의 구조 여기에서 각 모듈들이 하는 역활은 다음과 같다. 오실레이터 (Oscillator) : 소리를 발진 시킨다. 필터 (Filter) : 오실레이터로부터 받은 소리를 필터링 한다. 엠프 (Amp) : 필터를 거쳐온 소리를 증폭시켜서 최종적으로 출력한다. 모듈레이터 (Modulator) : 각 모듈(오실레이터, 필터, 엠프)에 ENV, LFO 신호를 줘서 변형을 준다. ENV (Envelope Generator) : ADSR의 패턴을 가지고 신디사이저의 모듈들을 컨트롤 할 수 있는 Envelope를 생성한다. 보통 키보드 게이트의 신호를 통해 작동되어 시간에 따라 변하는 전압(Envelope)을 생성한다. LFO (Low Frequency Oscillator) : 저주파 발진기로. 저주파 패턴을 만들어서 음성을 변조하는대 사용한다. 그리고 Serum에서 각 모듈의 위치는 다음과 같다. Serum의 모듈 위치 3. Serum 각 모듈별 사용법 - 오실레이터(Oscillator) 오실레이터에서 Osc A, B가 활성화 되어있다 오실레이터는 크게 Sub와 Noise, Osc A, Osc B로 이루어져 있다. Sub는 기본파형을 발생시킬수 있으며 Noise는 치지직거리는 배경 잡음을 발생시키고, Osc A와 B는 각각 웨이브테이블을 이용해 다양한 파형의 소리를 발진시킨다. 각 요소...
댓글 쓰기
자세한 내용 보기

윈도우 10 부팅시 자꾸 start process as current user get session user token failed 뜨는 현상 해결법

start process as current user get session user token failed 가 뜨는 경우는 분명 여러가지가 있으므로 이 해결책은 극히 일부의 문제에만 해당하는 해결법임을 명시합니다. 얼마전 컴퓨터를 부팅하는데 start process as current user get session user token failed 메시지가 뜨면서 부팅을 방해받았던적이있다. 물론 내 컴퓨터는 아니었지만, 딱히 그럴만한 이유가 떠오르지 않았다. 바이러스에 노출될 환경이 아니었기 때문이다.  그렇다면 문제가 무었일까? 나는 구글에서 검색을 해보았고 해당 문제를 겪고있는 많은 사람들을 볼 수 있었다. 특이한점은 내가 본사람들은 전부 한국 사람이었고 전부 11월 1일 이후로 이 문제를 겪고 있었다는 것이었다. 그리고 나는 이문제의 해결법을 찾았다. 다름아닌 vpwalletservice.exe 가 문제였다. 작업관리자에서 VPwalletservice 또는 그와 관련된 VP.inc에서 배포한 프로그램을 모두 종료하고 msconfig를 실행해 서비스 목록에서 vpwalletservice 와 관련 프로그램을 제외시켜야 한다. 이렇게 해결을 보고 지금은 문제없이 잘 사용중이다.
댓글 쓰기
자세한 내용 보기

윈도우 10 마우스(커서) 옆에 자꾸 Progress bar(진행중 아이콘)가 나타난다면

이 글은 윈도우10 사용자 중 자꾸만 마우스 커서 옆에 뭔가가 실행중이라고 진행 아이콘이 뜨는 사람에게 조그마한 희망을 주는 글 입니다. 또한 백그라운드에서 프로그램이 실행되는 경우는 아주 다양하니 이 글에서 제시하는 방법은 수많은 문제 중 한가지 문제의 해결책일 뿐임을 미리 알려드립니다. 본인은 원래 해당컴퓨터에서 바이러스에 걸릴만한 행위를 일체 하지않았다. 토렌트나 웹하드는 전혀 사용하지 않고 인터넷에서 파일도 대기업의 공인된 파일만 다운받아서 썼었다. 그러나 어느 날 부턴가 다음과 같은 현상이 발생하였다. 아무런 프로그램도 실행중이지 않지만 자꾸 마우스 아이콘에 실행중이라고 뜨는 문제였다. 이해를 돕기위한 삽화 나는 실행한 프로그램이 없지만 뭔가가 실행중이라는 것은 백그라운드 서비스가 원인이라는 것이다. 그렇다면 어떤 서비스가 다음과같은 현상을 야기했을까? 나는 작업관리자에서 의심가는 백그라운드 프로세스를 종료해보았다. 바로 vpwalletservice VP.Inc에서 배포한 프로그램이었다. 아니나 다를까 해당 프로세스를 삭제하자마자 현상은 사라졌다. 백그라운드 서비스인만큼 msconfig의 서비스 목록에서도 제거하였고 이제 확실히 이런 현상은 발생하지 않을 것이다. 해당 프로그램은 현재 여러 문제를 야기시키는 것으로 인터넷에서 유명하다. 얼마전에는 해당프로그램이 윈도우 부팅시에 start process as current user get session user token failed 메시지를 띄우게 만들어 부팅을 방해했던 문제도 직접 경험해 본적이있다. 이 경우에도 해결방법은 같다.
댓글 쓰기
자세한 내용 보기