논블로킹 IO나 가상 스레드를 적용할 때 먼저 검토할 것
논블로킹 IO나 가상 스레드 적용할 때는 먼저 다음을 검토하자.
- 문제가 있나?
- 문제가 있다면 네트워크 IO 관련 성능 문제인가?
- 구현 변경이 가능한가?
- 성능 문제가 없고 당분간 트래픽 증가 가능성 없다면 검토할 필요가 없다.
- 문제가 없는데 구현을 변경하는 것은 시간 낭비임.
- 논블로킹/비동기 IO 방식으로 구현하면 코드가 복잡해지고 유지보수 난이도가 올라감.
- 성능 문제가 있다면 네트워크 IO와 관련된 자원 문제인지 먼저 확인.
- 트래픽이 그대로인데 DB 쿼리 시간이 느려지면서 서버 응답이 길어지는 문제가 발생했다면 가상 스레드나 논블로킹을 적용해도 응답시간 줄일 수 없다.
- 논블로킹은 처리량만 향상시켜줄뿐임!
- 내 이해로는, 일단 많이 인풋은 시키는건데 아웃풋이 실질적으로 같을수있다 이러면 api server입장의 처리량은 별 차이 없을
- 논블로킹은 "하나를 빠르게" 처리하는 기술이 아니라, "동시에 많이" 버티는 기술
- 이벤트 루프 같은거하면 스레드 고갈이런게 없구나
- 이 경우 쿼리를 최적화 하거나 캐시를 도입하는게 방법.
- 썸네일 생성 처럼 CPU 중심 작업도 마찬가지.
- 이미지 처리하는 과정에는 블로킹 IO가 없으니 가상 스레드나 논블로킹 입출력 도입해도 처리시간이 같다.
- 문제가 IO 관련이라면 그때는 구현 변경이 가능한지 따져본다. 예를들어 동시에 요청하는 클라 수가 늘어나면서 실행되는 스레드 수도 많아졌고, 그 결과 메모리 사용률이 98%까지 올라갔다 하자. 이게 지속되면 장애 발생할수도있다. 가상 스레드를 적용할 수 있다면 이를 사용하기만해도 메모리 사용률 줄일수있음. 만약 없다면 일단 메모리 늘리거나 서버 수평확장해서 문제를 완화할수밖에 없음.
다른 상황으로는
- 우선 순위에 밀려 성능 개선을 뒤로 둘때.
- 기술에 대한 익숙함.
- 예를 들어 웹소켓 서버의 동접이 늘어 성능 문제 발생했다치자.
- 이때 논블로킹 입출력쓰면 효과 볼수있지만, 개발자가 관련 기술 모르면 성능 개선이 어려움.
정리하자면...
- 문제가 있다
- 그 문제가 네트워크 IO 관련이다
- 구현 변경이 가능한 상황이다
- 라면 변경 시도 ㄱㄱ