참조
servlet과 webflux
- 요약설명
servlet
- 기존 서블릿 구조는 블록킹&&동기적을 기존구조로 동작한다 따라서 아래처럼 request 1개당 1개의 Thread를 활용하는 구조이다.
- Thread per request model
- Servlet Connector를 BIO에서 NIO로 변경하면 쓰레드 idle 시간을 20~30% 줄이면서 connector -> Servlet 쓰레드 할당 시점에 성능을 다소 올릴 수 있지만 Thread 할당 시점 이후부터는 다시 thread per request model이 기본적이라는것은 변함이 없습니다.
- 더 많은 가용 Thread 를 Thread Pool에 할당해도 되지만, Core 수 이상의 더 많은 Thread가 사용되면 결국 Context Switching에 더 많은 비용이 들게됩니다. 결과적으로 유저가 많아지면 선형적으로 비용도 증가할 수 밖에 없는 구조입니다.
webflux
- Webflux는 상대적으로 적은 수의 쓰레드를 가지고 있으면서, 더 많은 요청이 발생했을때 효율적이고 안정적인 서버 퍼포먼스를 제공할 수 있는 EventLoop model을 지원하는 Netty를 기본 Servlet Container로 채택합니다.
- 기존 Servlet API를 사용하지 않고 asynchronous & non-blocking 용 공통 API가 새로 탄생함
- 작은 수의 스레드로 동시성을 처리하고 더 적은 하드웨어 리소스로 확장할 수 있는 non-blocking web stack이 필요했고. asynchronous & non-blocking 을 기반으로 작성된 공통 API를 새로 사용합니다.
- Reactive Streams는 back-pressure가 있는 asynchronous한 구성 요소 간의 상호 작용을 정의하는 규격 또는 사양입니다.(Java 9에서도 채택 됨) Reactive Streams의 주요 목적은 Subscriber가 Publisher가 보내는 스트림의 속도를 제어할 수 있도록 하는 것입니다.
Reactive Streams API는 저수준에 집약되어있어, 애플리케이션 개발에 유용하게 사용하지 못하는 경우가 많기 때문에 더 많은 애플리케이션 개발에 필요한 기능들을 사용하기위해 Reactive 라이브러리로 Reactor 라이브러리를 사용 합니다.
장점
- 비동기처리: 대량 트래픽 및 데이터에 대해 높은 성능과 효율성을 제공합니다.
- 백프레셔 지원: 시스템의 오버로드를 방지하고, 자원을 효율적으로 활용할 수 있습니다.
- 다양한 환경 지원: Servlet 컨테이너 뿐만 아니라 Netty, Undertow 등 다양한 실행 환경에서 동작 가능합니다.
단점
- 비동기 프로그래밍의 복잡성: 비동기 프로그래밍은 코드가 복잡해지고 디버깅이 어려울 수 있습니다.
- 데이터베이스 연결 제한: 대부분의 관계형 데이터베이스 드라이버는 차단 방식(blocking)으로 작동하므로, 이들은 WebFlux와 잘 호환되지 않습니다.
- 학습 곡선: WebFlux와 Reactor API에 익숙해지는 데 시간이 필요합니다.