Spring Webflux Event Loop 구조

요청, 애플리케이션에서 작업해야 하는 일들은 모두 **Event라는 단위로 관리**된다.

그리고 Event Queue에 적재되어서 순서대로 처리된다. (순차적으로 처리해서 Event Loop라고도 부름)

때문에 Spring Mvc의 Thread Per Request 방식보다 Context-Switching이 적다.

또한 Thread 개수가 Mvc의 개수보다 적기 때문에 Thread 경합도 적게 일어난다.

하지만…

Spring Webflux는 적은 스레드 때문에 Cpu사용량이 높거나, 오랜 시간이 드는 작업을 수행하기엔 비효율

또한 blocking I/O 작업을 처리하게 되면 Event들을 빨리 처리할 수 없기 때문에 성능 저하의 원인이 된다.

중요(성능 이슈가 있다면 주저하지 말고 코드 내에서 blocking 코드가 없나 확인하자)

• spring webflux에서 **blocking 처리를 사용하게 되면 전반적인 성능 하락의 원인**이 된다.

  non-blocking을 최대한 지향!

• **map은 동기식**으로 Mono의 아이템을 변경, **flatMap은 비동기식**으로 Mono의 아이템을 변경한다.

  flatMap을 사용하자

• DB와 연결하는 과정을 blocking으로 수행하면 성능 저하가 일어날 수 있다.

  DB와 연결할 때도 비동기식으로 수행하자.

참고 자료

내가 만든 Webflux가 느렸던 이유

Kotlin + Coroutine으로 개발하는 Non-Blocking API