Spring MVC vs Spring WebFlux

Spring MVC

스프링 MVC의 기본동작은 ThreadPerRequest이다. 

• Sync/Blocking
• 1 Request -> 1 Thread
• 많은 수의 Thread Pool을 사용한다.
• 스레드 수가 너무 많으면 컨텍스트 스위칭에 대한 비용이 증가
• 스레드 수가 너무 적으면 스레드 고갈로 인한 지연이 발생하는 문제점을 가지고 있다.

처리 순서는 다음과 같다.

• 일단 요청이 들어오면 스레드를 하나 할당 받는다.
• 요청은 Filter -> DispatcherServlet -> Controller로 전달되고, 해당 스레드는 IO작업이 발생하더라도 블락킹된다.

Spring WebFlux

스프링 WebFlux의 동작 방식은 EventLoop이다. 

• Async/Non-Blocking
• N Request -> 1 Thread
• N: M 이지만 상대적으로 N이 훨씬 많다.
• M의 블럭킹이 발생하면 심각한 성능저하가 발생한다.

처리 순서는 다음과 같다.

• Request가 들어가서 소켓에 바인딩 되어 이벤트큐에 쌓인다.
• Event Loop를 통해 작업이 Worker Thread로 할당이 된다. 
• 이벤트는 accept, read, write등으로 나누어져서 CPU를 활용한 작업만 빠르게 수행한 후 이벤트를 변경한다.

Performance

정말 많은 사람들이 다양한 성능테스트를 수행했다. 여러 케이스를 봤을 때 약 1.5배 정도의 성능 향상을 생각해볼 수 있다.

 

더 생각해보기

Spring MVC with Reactor

간혹 Functional Endpoint가 부담스럽거나 기존의 필터 구조를 유지하고 싶을 경우 위와 같은 구성을 할 수 있다. 이럴 경우 Controller 이전은 블럭킹 이후는 논블럭킹으로 동작하게 된다.

 

Spring MVC with Coroutine

스프링 MVC를 사용하고 코루틴을 사용하는 경우가 있다. 리턴은 runBlocking으로 하고 순수한 객체를 리턴한다. 이런 경우를 생각해보면 Corountine 레벨에서의 IO 스위칭의 이점을 볼 수 있지만 기본적으로 리퀘스트의 동작은 블록킹 형태가 될 것이다.

 

출처 :

https://singhkaushal.medium.com/spring-webflux-eventloop-vs-thread-per-request-model-a42d07ee8502

Spring Webflux: EventLoop vs Thread per Request Model

https://filia-aleks.medium.com/microservice-performance-battle-spring-mvc-vs-webflux-80d39fd81bf0

Microservice performance battle: Spring MVC vs WebFlux