Blocking IO, Non-Blocking IO . 대규모 접속을 수용할 수 있는 원리

IO(Blocking) 

• stream oriented
• stream으로부터 한번에 한개 이상의 byte를 읽는다는 것을 의미

• Java IO의 많은 stream들은  blocking 이다. 
• 쓰레드가 read(), write() 동작을 시키면 thread는 data를 읽을때까지 block된다.

NIO (Non-blocking IO)

• buffer oriented
• 최근 프로세스에서 버퍼를 읽음

• Java NIO는 non-blocking이다.
• thread는 channel에 데이터를 쓰도록 요청할 수 있다. 하지만 write 동작이 끝날때까지 기다리지 않는다.

---------- 위까지는 학문 느낌의 정의? 라고 할까. 무슨 말인지도 잘 모르곘지만 사례를 들어 생각하면 이해가 좀 쉽다. WAS

Blocking IO Webserver 

• 하나의 호출마다 thread를 생성한다.

Non-Blocking IO Webserver

• 요청을 받는 thread는 오직 하나다.

Blocking IO 의 장점 

•  호출마다 thread를 생성하니 요청이 적은 서비스에는 최적의 성능을 낼 수 있다. (병렬 작업의 장점)

Non-Blocking IO 의 장점

• Blocking IO의 경우 요청마다 thread를 생성하는 부분에서 부하가 크다. 이 부분이 없다.
• Blocking IO의 경우 context-switching이 빈번하게 발생할 수 있다.
• Non-Blocking IO 는 요청을 받는 부분이 단일thread이기 때문에 요청마다 thread를 생성하지도 않으며, context-switching에 대한 걱정도 없다.
• Context-switching은 OS 단에서 처리하는데 이것을 사용자(개발자)가 직접 처리한다는 개념에서 최적화(?) 시킬 수 있다는 장점이 있다.

Non-Blocking IO는 사용을 잘? 해야만 한다.

• 멀티코어 장비로 single thread 작업 하나만 돌린다면? over-spec 아닌가? 생각해볼 필요가 있을 것이다.
• 그렇다면 core개수당 thread를 띄우면 될 것인가!? - 연구가 필요할 것 -> nginx를 예로 들면 thread를 몇개 생성할 것인지 지정할 수 있다.

그렇다면 Non-Blocking IO를 사용하면 장땡 아닌가?

• Non-Blocking IO를 사용한다고 해서 극적인 성능향상을 기대할 수만은 없다. (대규모 클라이언트 접속상황에서 성능향상은 분명하다. - 10k problem 사례)

  왜냐하면 보통 WAS는 하나의 요청당 DB 접근을 하게끔 되어 있는데, 현재 stable버전의 DB 중에는 async 한 것이 없기 때문이다.
  WAS가 async해도 DB가 sync하다면 DB에서 정보를 불러오는데서 lock이 걸릴 것이다. 때문에 지금도 async한 DB를 만드는 작업이 진행 중이라 한다. (현재는 beta버전)

Non-Blocking IO의 극적인 성능향상 사례 

http://en.wikipedia.org/wiki/C10k_problem

http://www.webcitation.org/6ICibHuyd <- 특히 너무 좋은 정보가 너무너무 많다. 필독

• 10k problem
• 1만 커넥션을 버티는 구조
• 당시 1999~2001년 512MB RAM의 서버장비로, Blocking IO 구조는 1천클라이언트를 견디는 구조였다. 
• 지속적인 클라이언트 증가를 견디기 위해 처음으로 Non-Blocking IO 연구가 시작되었고 마침내 1만커넥션을 수용하는데 성공했다는 일화이다.