mvc만 써와서 웹플럭스를 왜쓰는지 몰랐는데 오늘 알게되서 대충 적어보는데 맞는지 확인좀 (백프레셔같은 다른 기능들은 제외, io관점만 봄)
톰캣같은 one thread per one request 인 모델은 기본적으로, 요청 흐름이 사용자 코드쪽으로 넘어올때부터 스레드하나가 할당되고 다시 나갈때까지 그 스레드를 물고있음.
이 상태에서 io바운드, 특히 쿼리튜닝같이 내가 직접 속도 제어가 불가능한 http api 콜하는경우에는 직렬로 느려질수밖에 없음. 병렬 속도를 내기 위해 비동기작업을하면 추가스레드가 필요함. 한두개면 괜찮지만, 트래픽이 많이 들어오고 추가스레드가 많아지면 많아질수록 컨텍스트 스위칭 비용에 낭비되는 오버헤드가 부담이 됨
웹플럭스를쓰면 밑단에 있는 네티를 통해 nio 를 활용해서 이 부분에 대한 오버헤드를 줄여줌. io 멀티플렉싱으로 필요한 스레드 수가 석어지니, 스레드에 대한 컨텍스트 스위칭 비용이 감소됨. 톰캣위에서도 nio 처리는 가능하겠지만 내츄럴하게 지원하는 부분이 아니다보니 구현이 까다로움
웹플럭스의 강점을 한줄 요약하자면 트래픽이 많은 상황에서 병렬로 서로 다른 api를 콜해야하는 상황이 많아질때의 쓰루풋.
이렇게 대충 이해했는데 맞음?
톰캣같은 one thread per one request 인 모델은 기본적으로, 요청 흐름이 사용자 코드쪽으로 넘어올때부터 스레드하나가 할당되고 다시 나갈때까지 그 스레드를 물고있음.
이 상태에서 io바운드, 특히 쿼리튜닝같이 내가 직접 속도 제어가 불가능한 http api 콜하는경우에는 직렬로 느려질수밖에 없음. 병렬 속도를 내기 위해 비동기작업을하면 추가스레드가 필요함. 한두개면 괜찮지만, 트래픽이 많이 들어오고 추가스레드가 많아지면 많아질수록 컨텍스트 스위칭 비용에 낭비되는 오버헤드가 부담이 됨
웹플럭스를쓰면 밑단에 있는 네티를 통해 nio 를 활용해서 이 부분에 대한 오버헤드를 줄여줌. io 멀티플렉싱으로 필요한 스레드 수가 석어지니, 스레드에 대한 컨텍스트 스위칭 비용이 감소됨. 톰캣위에서도 nio 처리는 가능하겠지만 내츄럴하게 지원하는 부분이 아니다보니 구현이 까다로움
웹플럭스의 강점을 한줄 요약하자면 트래픽이 많은 상황에서 병렬로 서로 다른 api를 콜해야하는 상황이 많아질때의 쓰루풋.
이렇게 대충 이해했는데 맞음?
성능 개선도 있고 비용 절감도 되고 만능입니다 웹플럭스 하십쇼 체질이라는게 달라집니다
이거보고 오늘 r2dbc펼쳤다 - dc App
async 가 기본인 언어를 쓰면 정말 편할탠데 말이지
mvc에서 논블로킹 api 콜을 못하는줄 아네