SpringWebflux 학습내용 정리 (2)

Kevin의 알기 쉬운 Spring Reactive Web Applications 정리

리액티브 프로그래밍과 리액티브 시스템에 관한 개념을 정리

Non-Blocking I/O 방식은 리액티브 시스템 설계 원칙의 한부분!

Blocking I/O 방식 Full-width image

  • 작업 쓰레드가 종료될 떄까지 요청 대상 쓰레드는 차단됨
  • 단점 보완하기 위해 멀티 쓰레딩 기법을 통해 처리 가능
  • CPU 대비 많은 스레드를 사용하는 어플리케이션은 비효율적
  • 컨텍스트 스위칭으로 인한 쓰레드 전환비용 발생
  • 메모리 사용에 있어서 오버헤드 (플랫폼 스레드당 1MB)
  • 쓰레드 풀에서의 응답지연 문제 발생(반납 과정에서)

Blocking I/O 방식의 문제점 Full-width image

  • PCB에 저장하고 로드하는 추가시간이 있기 때문에 실행시점과 유휴 시점이 딱 들어맞지 않는다.
  • PCB 저장/로드 시간동안 CPU는 대기
  • 컨텍스트 스위칭이 잦을 수록 CPU의 전체 대기시간이 길어짐
  • 쓰레드는 하나의 프로세스 정보를 공유하기 때문에 프로세스의 컨텍스트 스위칭 비용보다는 낮지만 그래도 PCB 저장/로드 시의 비용이 발생함
  • 메모리 사용 오버헤드 발생
  • 64-bit JVM = 1,024 KB 스택사이즈 사용
  • 64,000명 접속시 64GB 메모리 필요

Non-Blocking I/O 방식 Full-width image

  • 작업 쓰레드의 종료와 상관없이 요청을 한 쓰레드는 차단되지 않음
  • Request Per Thread를 사용하는 블락킹 방식보다 전환 비용이 적게 발생함
  • CPU 대기 시간 및 사용량에 있어서도 효율적
  • CPU를 많이 사용하는 작업이 포함되어 있을 경우 성능 향상에 악영향을 준다
  • 사용자 요청에서 응답까지 Blocking I/O가 있는 경우 Non-Blocking 의 이점을 발휘하기 힘들다

© 2019. All rights reserved.

Powered by Hydejack v8.1.1