IO(input/output) model

IO 모델

전통적인 IO 모델(Blocking I/O)

blocking io를 사용하는 방법으로, Multi-Threaded Request-Response 형태이다.

concurrent 요청을 처리하기 위해서, 쓰레드를 관리해 사용한다.

IO가 시작되었을때, 어플리케이션이 blocked, IO가 끝날 때까지 대기

프로세스 단계

1. 클라이언트가 서버로 요청
2. 서버는 내부적으로 한정된 스레드 풀을 유지 관리하여 클라이언트 요청에 서비스를 제공
3. 서버는 무한루프에 있으며, 클라이언트 요청을 기다림
4. 서버가 다수의 요청을 받음
5. 서버가 하나의 요청을 선택(SELECT)
6. 쓰레드풀로 부터 하나의 쓰레드를 선택
7. 요청을 쓰레드에 할당
8. 쓰레드에서 bloking io를 처리(ACCEPT, RECV) 및 응답준비
9. 쓰레드는 응답을 서버로 보냄
10. 서버는 다시 클라이언트에서 응답을 보냄(SEND)

NIO(Non-Blocking I/O) 모델

blocking io보다 개선된 형태로, 요청을 계속 기다리지 않는다. io처리를 위해서, 쓰레드를 사용할 필요가 없다.(단일 쓰레드로 처리가능)

소켓채널을 관리할 특정 객체가 필요함(여기선 채널매니저라 칭함)

IO가 시작되었을때, 어플리케이션이 block되지 않지만, IO 상태를 계속해서 확인(system call return EAGAIN or EWOULDEBLOCK)

프로세스 단계

1. 클라이언트가 서버로 요청
2. 서버는 무한루프에 있으며, 클라이언트 요청을 기다림
3. 서버가 다수의 요청을 받음
4. 서버가 하나의 요청을 선택(SELECT)
5. 해당 소켓채널을 채널매니저로 보냄
6. 채널매니저에서 소켓채널을 순회하며 non-blocking io를 처리(ACCEPT, RECV) 및 응답준비
7. 채널매니저는 응답을 서버로 보냄
8. 서버는 다시 클라이언트에게 응답을 보냄(SEND)

비동기(Asynchronous I/O) 모델

위의 전통적인 방식은 모두 동기화 방식이다.

Blocking IO의 대안인 Non-Blocking IO 또한, 잦은 system call과 context switching으로 인해, 사실 매우 비효율적이다.

system call에 대한 응답을 받는 과정이 동기가 아닌 비동기로 동작한다는 개념이다.

즉, read같은 io를 콜하고, 응답이 올때까지, 다른 작업을 할 수 있다.

개념적으로는 매우 훌륭하지만, 이 또한 단점이 있는 것 같다.

IO처리는 OS담당이라, linux에서는 kqueue, epoll을 사용하며, windows는 IOCP를 사용하는데, 이게 이벤트 핸들링 패턴이 다르다.

리눅스의 경우 aio의 콜백은 비동기이지만, 실행되는 쓰레드가 어플리케이션이 아닌, 시스템 쓰레드라고 한다.(정확한 조사가 필요함)

윈도우즈의 경우는 다른지 모르겠지만, 

AIO가 NIO를 대체할 녀석은 아닌것으로 보인다.

잦은 system call과 context switching을 줄였지만, 실제 성능에는 도움이 되지 못하고, 구조만 복잡해지는 결과를 초래한 것일까??

고성능 IO처리

싱글 쓰레드 이벤트 루프

내용추가 계속

ref: http://www.journaldev.com/7462/node-js-architecture-single-threaded-event-loop

ref: https://slipp.net/wiki/pages/viewpage.action?pageId=19530144

ref: http://djkeh.github.io/articles/Boost-application-performance-using-asynchronous-IO-kor/

ref: https://www.ibm.com/developerworks/library/l-async/

ref: https://github.com/netty/netty/issues/2515