[spring] mvc, webflux, coroutine 간단 비교 정리

[backtony]

mvc

• 스레드가 i/o 블럭되면 끝날때까지 대기한다.
• 그렇다고 cpu가 일을 안하는 건 아니고 다른 스레드가 점유해서 일을 한다.
  • 하지만 스레드가 전부 블럭되면 cpu가 놀게 된다.
• cpu를 점유할 수 있는 시간을 제어하는 time slice 형태로 짤라두고 스레드가 그 시간을 다쓰면 다른 스레드가 점유하게 되면서 context switching이 발생한다.
  • tomcat은 200개의 default 스레드로 진행되므로 context switching이 많아질수록 성능에는 안좋아지고, context switching 도중에는 cpu가 아무런 일도 못한다.

webflux

• event 기반으로 동작하므로 모든 요청은 이벤트 큐에 쌓이고 이벤트 루프가 돌면서 worker thread에 일을 할당한다.
  • worker thread가 i/o 블럭 당하면 i/o 이후의 동작이 이벤트 큐에 들어가고 쓰레드는 다시 풀로 돌아가면서 다음 일을 할당받는다. 그래서 하나의 요청에서 i/o가 발생하면 하나의 스레드가 계속 점유하지 않게 된다.
• webflux는 코어당 스레드가 1개씩 배분될 수 있도록 worker thread를 관리한다. webflux의 베이스인 netty는 core * 2를 worker thread로 관리하는데 *2로 띄우는 이유는, cpu에서는 코어당 2개의 스레드를 사용할 수 있는 하이퍼 스레딩이라는 하드웨어 스레드가 지원되기 때문이다. 결론적으로 코어수에 딱 맞는 스레드 개수를 관리하기 때문에 context swtiching이 발생하지 않는다.

coroutine

• 코틀린 컴파일러에 의해 CPS 패턴으로 변환된다.
  • 컴파일되면 리턴값이 사라지고, 마지막 인자로 continuation을 넘긴다.
  • continuation으로 context를 전달하기 때문에 context swtiching이 발생하지 않는다.
• coroutine dispatcher에 의해 적절한 스레드에서 실행/재개 된다.
• 스레드는 time slice 이후에는 다른 스레드에게 cpu 점유를 양보하는 반면에, 코루틴은 suspend 일시 중단 지점까지 제어권을 양도하지 않고(비선전형) 동작한다.