Spring MVC Vs. Spring WebFlux

Spring MVC

특징

• Sync / Blocking
• 1 request -> 1 thread
• Thread Pool을 관리하고 (기본 200개) idle thread 하나를 꺼내 요청을 처리함
• I/O Blocking 시간에 다른 일을 못함

Thread가 많은 경우(Thread Context Switching)

• kernel mode에서는 CPU는 아무일도 하지 않음. (User mode의 입장에서는 그냥 오버헤드)
• 실행 중인 스레드가 적을 경우에는 별 차이 없지만 스레드가 많을 경우에는 이야기가 달라진다.

• Thread를 많이 만들 경우에 잦은 Context Switching로 인한 Time Slice가 증가한다.

Thread가 없는 경우

• Spring MVC는 Request : Thread = 1 :1, 그래서 모든 Thread가 I/O Blocking에 걸려서 요청을 못 처리 한다. 하지만 Core (CPU)는 여유로운 상태다.

Thread Pool Dilemma

• Thread를 늘리면
  • 메모리, CPU 부하로 성능 저하 (Context Swiching)
• Thread를 줄이면
  • 메모리, CPU는 충분하지만 Thread가 모자라서 처리율이 저하된다.

Spring WebFlux

• Async / Non-Blocking
• N Request -> 1 thread (N:M인데 N이 굉장히 많음)
• 처리 과정
  • Request가 들어가서 소켓에 바인딩 되어 채널에 쌓인다.
  • Event Loop를 통해 작업이 Worker Thread로 할당이 된다. 이 때 Worker Thread에 Spring WebFlux Controller (굉장히 많은 task들로 구성되어 있음) 가 적재가 된다.
  • Controller를 구성하는 Task는 바로 실행되지 않고 Event Queue 에 적재가 된 이후 순차대로 놀고 있는 Worker Thread에서 처리가 된다. (N:M인데 N이 굉장히 많음)
• Thread Pool (Wokrer Thread)이 기본적으로 적다 (Core x 2)

Reactor의 Event Loop

• Publisher에서 subscribe 를 실행하는 순간 Task들은 Event Queue에 쌓임
• Event Loop (main / Single Thread)는 Event Queue에서 값을 하나씩 꺼내서 Worker Thread에 분배된다.
• Task에서 Return을 받을 경우 Event Loop 는 해당 콜백을 다시 Event Queue에 넣는다.
• 스레드는 최소 2개가 필요하다 (Event Loop 담당 / Worker 담당)
• Reactor Netty는 사용 가능한 CPU 코어 수에 따라 이벤트 루프 그룹을 생성.

• Reactor의 Task Chained에서 다음 Chain을 실행하기 위한 Context가 파라미터 형태로 넘어가기 때문에 Worker Thread에서 Context Switching이 발생하지 않음.
• Thread를 효율적으로 쥐어 짜내기 가능

WebFlux의 단점

• MVC보다 느릴 수 있다.
  • 적은 리소스로 많은 트래픽을 감당하는 개념
  • WebFlux는 OS에서 스레드 시간을 제어하는 기능이 없음. → 즉 특정 task가 Blocking으로 동작할 경우 해당 코드가 전체 처리 속도에 악영향을 미친다.