멀티 쓰레드

클라이언트에서 요청을 하면 TCP/IP 연결이 되고 servlet이라는게 호출 된다.

이 서블릿을 누가 호출하냐. 바로 쓰레드라는 것이 호출한다.

클라이언트 요청이 오면 WAS에서 쓰레드를 할당하고 그 쓰레드가 servlet 코드를 실행하는 것.

만약 다중 요청이 들어오는데 단일 쓰레드라면?

요청1에 대한 쓰레드를 할당하고 servlet을 실행하는데 어떤 이유에서 처리가 지연되고 있는 상황에서 요청2가 들어온다면 코드를 실행할 수 있는 쓰레드는 하나이기 때문에 요청2는 대기해야한다.

그냥 요청마다 쓰레드를 생성하도록 하면 된다.

근데 요청마다 쓰레드를 생성할 때의 장단점이 있다.

장점
- 동시 요청을 처리할 수 있다
- 리소스가 허용할 때까지 처리가 가능하다
- 하나의 쓰레드가 지연되어도, 나머지 쓰레드는 정상 동작한다.
단점
- 쓰레드 생성 비용이 비싸다(자원이 많이 든다)
  - 그래서 요청이 들어올 때마다 쓰레드를 생성하면 응답속도가 늦어진다.
- 쓰레드는 컨텍스트 스위칭 비용이 발생한다.
  - CPU 코어 하나가 쓰레드를 동시에 수행할 수 없다. 사실은 쓰레드들을 번갈아가면서 작업을 처리하는데 코어 하나가 쓰레드들을 왔다갔다 할때 드는 자원을 컨텍스트 스위칭 비용이라고 한다.
- 쓰레드 생성에 제한이 없다.
  - 고객 요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다.

이런 단점을 해결하기 위해 보통 WAS들을 Thread Pool 이라는것을 사용한다.

쓰레드 풀은 쓰레드들을 미리 만들어 놓은 수영장이라고 생각하면 된다.

그래서 요청이 들어오면 쓰레드 풀한테 요청을 한다. 놀고 있는 쓰레드 달라고.

그리고 쓰레드를 다 쓰면 그 쓰레드를 죽이는게 아니고 다시 쓰레드 풀에 반납을 한다. 왜냐? 쓰레드를 생성하는데 드는 비용이 비싸니까

근데 쓰레드 풀에 있는 쓰레드를 다 사용하고 있는데 또 요청이 들어온다면?

그럼 쓰레드 풀은 요청을 대기시키거나 거절 할 수 있다.

특징

사용

장점

WAS의 주요 튜닝 포인트는 최대 쓰레드 수 이다.
최대 쓰레드가 너무 낮게 설정하면
- 동시 요청이 많을 때 서버 리소스는 여유롭지만 클라이언트는 금방 응답 지연을 겪게된다.
- 서버 자원을 적절하게 사용하지 못하는 것이고, 많은 동시 요청을 처리하기 위해서 서버가 증설되고 있다면 돈낭비 하는 것이다.
최대 쓰레드를 너무 높게 설정하면
- 예를 들어 10000개를 설정한다. 그럼 10000개의 요청을 다 받는 것이고, CPU, 메모리 자원 초과 문제로 서버가 다운된다.
장애 발생시
- 클라우드면 일단 서버부터 늘리고, 이후에 튜닝
- 클라우드가 아니라면 그냥 열심히 튜닝

틈틈이 꾸준하게.