이 글은 foward의 세션 26번
나의 Webflux가 느린 이유 영상을 보고 쓴 메모와 제가 이해한 부분을 덧붙여 작성한 글입니다.
https://www.youtube.com/watch?v=I0zMm6wIbRI
https://forward.nhn.com/2020/session/26
Spring WebFlux 선택 이유
현재 서버에서 요구하는 스펙이 빠른 응답 속도와 높은 처리량이므로,
이에 맞는 WebFlux 스텍을 사용한 것입니다.
RDB + Spirng MVC 라는 선택지도 있지만
광고 노출을 담당하는 서버는 WebFlux가 적합하기에 이를 선택했습니다.
Spring MVC와 WebFlux의 Thread model 차이점
Spring MVC
- Thread Per Request Model
- Thread 개수 == 200
이 모델은 클라이언트에서 요청이 오면 서버는 이 요청을 처리하기 위해
Thread Pool에 있는 Thread 하나를 가져와 할당합니다.
할당한 Thread는 요청을 받고 응답할 때까지 모든 작업을 처리하게 됩니다.
WebFlux EventLoop
- EventLoop Model
- Thread 개수 == Core 의 개수 * 2
Spring WebFlux는 EventLoop Model로 동작하는데,
모든 요청과 애플리케이션 내의 작업을 Event라는 단위로 관리하고
이 들어온 Event들은 Event Queue에 적재되어 차례대로 처리됩니다.
이때 Event를 처리하는 Thread pool이 존재하는데, Event Queue에서 Event를 하나씩 뽑아 처리하게 됩니다.
처리 방식
Spring MVC는 하나의 작업을 실행하면 그 작업이 완료될 때까지 기다립니다.
예를 들어 유명한 음식점에 가서 사람이 많아서 기다려야 하는 상황이라고 가정해봤을 때,
Spring MVC는 번호표를 받고 그 자리에 서서 식당 안에 자리가 남을 때 까지 아무것도 하지 않고 기다리는 것입니다.
Spring WebFlux는 번호표를 받고 직원 분이 나에게 와서 이렇게 말해주는 것이다. "XX시 XX분에 오시면 자리 남을 거에요 그러니 그때 와주세요~" 그럼 나는 이 기다리는 동안 할 수 있는 다른 일을 하고 시간이 되면 다시 음식점에 가서 밥을 먹는 것입니다.
다시말해, 기다려야 할 때 다른 일을 할 수 있는 지가 가장 큰 차이점이라고 할 수 있습니다.
WebFlux는 이렇듯 기다리는 시간이 없도록 하여 처리량을 끌어올리는 것이 가장 큰 특징이라고 할 수 있습니다.