갑자기 1000번의 요청이 WAS에 들어오면 WAS는 어떻게 처리할까? 요청은 어떻게 처리되는 것일까? 많은 요청이 들어오면 응답이 느려지는데 왜 그런 것일까?
이러한 질문들은 모두 쓰레드와 연결되어 있다. WAS에 요청이 들어오면 쓰레드가 생성되어 로직을 실행하기 때문이다.
쓰레드는 하나의 제어흐름이라 할 수 있다. 우리가 자바 프로젝트를 생성하면 생기는 main 함수를 실행하면 main이라는 쓰레드가 실행되면서 순서대로 로직을 실행하는 것처럼 말이다.
WAS에 1개의 쓰레드가 있다고 가정해보자, A라는 클라이언트가 서버에 요청을 하여 쓰레드가 실행 중인데 B라는 클라이언트가 또 서버에 요청을 한다면 쓰레드가 작업을 완료할 때까지 B는 기다려야 할 것이다.
그래서 이러한 일이 생기지 않게 WAS는 멀티 쓰레드를 제공한다. 다수의 클라이언트가 요청을 보내도 기다리지 않고 동시에 작업을 처리할 수 있게 된다.
쓰레드를 요청마다 생성하게 된다면 동시 요청을 처리할 수 있어 분명 좋을 것이다. 리소스가 허용하는한 처리가 가능할 것이다. 또한 하나의 쓰레드가 지연 되어도, 나머지는 잘 작동 할 것이다.
그러나 치명적인 요청마다 쓰레드를 생성하는 것은 치명적인 단점이 존재한다.
그래서 쓰레드 풀이라는 것이 존재한다. 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다. 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리하는데 톰캣의 경우에는 200개가 기본 설정이다. 물론 이 숫자는 수정이 가능하다.
요청시 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 가져다 사용하고 사용을 마친 쓰레드는 다시 쓰레드 풀에 반납된다. 만약 쓰레드 풀에 있는 쓰레드가 모두 사용 중이라면 요청이 거절되게 하거나 일정 시간 혹은 숫자만큼 대기할 수 있도록 설정이 가능하다.
쓰레드가 미리 생성되어 있어 쓰레드를 생성하고 종료하는 비용이 절감되고 응답이 빠르다. 또한 생성 가능한 쓰레드의 최대치가 고정되어 있어 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다는 장점이 존재한다.
쓰레드 풀의 쓰레드 갯수를 너무 높게 설정하는 것만이 좋은 것은 아니다. 물론 서버의 CPU와 메모리의 성능이 매우 좋으면 높게 설정하는 것이 좋은 방법일 수 있으나 그렇지 않으면 CPU나 메모리가 임계점 초과로 서버가 다운될 수 있다.
그렇지만 너무 낮게 설정하는 것 또한 좋지 않다. 왜냐하면 요청이 많이 온다면 쓰레드의 갯수가 적어 쓰레드의 수만큼의 요청만 수행이 되고 나머지는 대기하거나 거절될 것이다. 근데 CPU의 사용량은 적어 서버의 효율성이 떨어진다. 이렇게 지속된다면 아마 요청이 밀려 WAS는 살아있을지언정 서비스가 장애가 날 것이다.
적정한 쓰레드의 수는 해당 어플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 등 상황에 따라 다르기 때문에 개발자가 적정한 수를 설정해야 한다.
성능 테스트를 통하여 최대한 실제 서비스와 유사하게 테스트를 하여 그 결과를 보고 설정하는 것이 좋다.
WAS는 멀티 쓰레드를 지원하기 때문에 개발자가 이러한 부분을 설정만 잘해주면 된다. 개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발하면 된다. 주의할 점은 멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용해야 할 것이다.