기존 SpringFramework의 프레임워크중 하나인 Spring MVC는 서블릿 API와 서블릿 컨테이너용으로 구성되었다.
다만 점차 Reactive Stack이 발전하면서, 스프링프레임워크 5.0 버전이후부터는 Reactive stack의 웹프레임워크인 SpringWebFlux를 개발하였다.
SpringWebFlux는 non-blocking을 지원하며 ReactiveStream의 back pressure와 함께 Netty , Undertow, Servlet3.1+ 컨테이너와 같은 서버에서 실행된다.
특징 | Spring MVC | Spring WebFlux |
---|---|---|
프로그래밍 방식 | 명령형 프로그래밍 | 함수형 프로그래밍 |
라이브러리 / API | Blocking | Non-Blocking |
서버 | Tomcat, Jetty | Tomcat, Jetty, Netty, Undertow |
쓰레드 모델 | Request per Thread | Event Loop |
Spring MVC는 명령형 프로그래밍 형식으로 코드를 작성한다. Blocking 라이브러리를 사용하기 때문에, Request Per Thread. 즉 하나의 요청당 하나의 쓰레드를 사용한다.
생각해보자.
요청이 들어올때 마다, 쓰레드를 생성하는것은 많은 cost가 발생하기 마련이다. 따라서 쓰레드풀을 만들어 쓰레드를 재사용하게 된다.
요청이 들어오면 요청을 큐에 쌓은 다음, 쓰레드풀에서 사용 가능한 쓰레드가 요청을 처리한다.
대신 이런 경우, 쓰레드 풀 갯수보다 많은 요청이 들어오면 큐잉되면서, 처리를 못하는 요청이 늘어난다.
처리를 대기하는 요청은 wait time이 발생하게 되고, 이때문에 성능이 저하될 수 밖에없다.
따라서 Spring MVC에서는 쓰레드풀의 개수를 잘 조절해야한다.