쓰레드 풀을 이용한 쓰레드 관리

최근에 계속 쓰레드에 관해서 공부하고 있다.

 

이번에는 Servlet 관점에서 보는 쓰레드 관리에 관하여 포스팅 하겠습니다.

 

먼저, Servlet 관점에서의 쓰레드를 보기 전에 웹의 요청 및 응답 흐름에 대해서 간단히 살펴보도록 하겠습니다.

 

 

먼저, 위 그림은 클라이언트에서 서버로 HTTP 요청을 보내고 서버는 이에 대한 응답을 주는 사진입니다.

 

과정을 정리해보자면,

 

1. HTTP 요청시 WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출합니다.
2. 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용한다.
3. 개발자는 Response 객체에 HTPP 응답 정보를 편리하게 입력한다.
4. WAS는 Response 객체에 담겨있는 정보로 HTTP 응답 정보를 생성한다.

 

2~3번에서 비즈니스 로직을 수행합니다.

 

여기서, 서블릿 컨테이너란??

서블릿 컨테이너는 서블릿을 생성,호출,관리해준다!

- 서블릿 객체는 싱글톤으로 관리한다.
- 동시 요청을 위한 멀티 쓰레드 처리를 지원한다.
- 서블릿 컨테이너는 서블릿을 지원하는 WAS이다!

 

따라서, 그림에서 웹 어플리케이션 서버라는 큰 틀로 묶은 것!

---

 

그렇다면, 서블릿 객체를 호출하는 주체는 누구인가??

 

답은 스레드입니다.

 

스레드는 애플리케이션 코드를 하나하나 순차적으로 실행하는 데, 자바를 예를 들면, main이라는 스레드를 실행하는 것이다.

 

비효율적인 스레드 관리

---

만약 하나의 요청이 온다면, 쓰레드를 하나를 사용해서 처리한다.

 

• 이후에 처리가 완료다면, 쓰레드는 휴식을 한다.
• 만약 처리를 못 한다면, 다음 요청은 ‘대기’상태가 된다.

만약, 다중 요청이 온다면 쓰레드를 요청 개수마다 생성시킬 수 있다.

 

• 처리가 완료가 된다면, 다음 요청을 처리하면 된다.
• 처리 중이라고 해도, 다른 쓰레드를 만들어서 요청을 처리하면 된다.

 

그러나. 이렇게 할 시에 비효율적인 부분이 있다.

• 스레드 생성 비용이 매우 비싸다. 따라서, 고객의 요청이 올 때 마다 스레드를 생성하면 응답 속도가 늦어진다.
• 스레드는 컨텍스트 스위칭 비용이 발생한다.
• 스레드 생성에 제한이 없다. → CPU, 메모리 임계점이 넘어서 서버가 죽을 수 있다.

 

따라서, ‘스레드 풀’ 이라는 개념이 등장한다!!

 

스레드 풀

---

스레드 풀은 스레드를 요청 마다 생성하는 것의 단점을 보완한 방법으로 생성 가능한 스레드의 최대치를 관리한다.

 

스레드 풀을 도입할 시 스레드가 사용되는 과정

 

1. 요청이 와 스레드가 필요하다면, 이미 생성되어 있는 스레드를 스레드 풀에서 꺼내서 사용한다.
2. 요청을 처리한 후(=스레드 사용 완료) 스레드 풀에 해당 스레드 풀을 반납한다.
3. 만약, 스레드가 모두 사용 중이서 스레드 풀에 스레드가 없다면 사용 중인 스레드가 반납될 때까지 대기한다!

 

중요한 것 : WAS의 주요 튜닝 포인트는 최대 스레드 수이다.

 

 

• 이 값을 너무 낮게 설정한다면, 서버 리소스는 여유롭지만, 클라이언트는 응답이 지연된다.
• 반대로, 이 값은 너무 높게 설정한다면 CPU, 메모리 리소스 임계점 초과로 서버는 다운된다.

조건 : CPU는 최소 50% 이상은 사용해야된다!

 

따라서, 쓰레드 풀을 적절하게 설정하는 것이 매우 중요한데 이는 성능 테스트로 해결한다.

 

'nGrinder' 라는 테스트 툴을 사용한다고 한다! 

 

 

지금까지 Servlet 관점에서 본 쓰레드 관리에 대하여 포스팅하였습니다.

 

 

 

출처 : https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard