보면 위가 서블릿 코드인데 비즈니스로직을 제외한 나머지 코드가 한개도 없다.
바로 HttpServlet을 extends 해왔는데 이게 @WebServlet 어노테이션과 함께 나머지 불필요한 일련의 과정을 생략할 수 있도록 도와주는 것이다.
그래서 urlPatterns의 URL이 호출되면 해당 서블릿 코드가 실행되고
HTTP req 정보를 편리하게 사용할 수 있는 HttpServletRequest,
HTTP res 정보를 편리하게 사용할 수 있는 HttpServletResponse,
그리고 이것들로 인하여 개발자는 HTTP 스펙을 매우 편리하게 사용할 수 있다.
servlet을 지원하는 WAS 안에는 Servlet container라는게 있는데
이 Servlet container가 servlet 객체를 자동으로 생성, 호출해준다.
또한 WAS가 내려갈 때 같이 종료하며 생명주기 관리도 해준다.
톰캣처럼 Servlet을 지원하는 WAS를 Servlet container라고 한다.
ServletContainer는 Servlet객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리한다.
Servlet객체는 싱글톤으로 관리된다.
JSP도 Servlet으로 변환되어서 사용
동시 요청을 위한 멀티 쓰레드 처리 지원 -> 따로 개발자가 신경쓰지 않아도 WAS가 다 알아서 해줌
그럼 만약 쓰레드가 하나인 상황을 가정해보자. 사용자 1이 req를 보냈고 이게 DB이든 로직이든 어떠한 일련의 문제로 굉장히 처리가 지연되고 있다고 가정할 때 사용자 2가 요청을 보내면 쓰레드가 1개밖에 없기 때문에 굉장히 요청이 지연된다. 그리고 나면 나중에 timeout이 나서 둘다 오류를 받을 것이다.
그럼 이 상황을 해결할 방법이 없을까?
답은 굉장히 단순하다 그냥 Thread를 하나 생성하면 된다.
그래서 req마다 그냥 Thread를 생성하면 된다. -> 그런데 딱 봐도 뭔가 단점이 있을 것 같지 않은가?
장점
단점
서버의 cpu에 코어 수에 맞춰 미리 Thread를 생성해두고 한 곳에 모아두면 그게 Thread pool이고 무한정 생성하는 것이 아닌 서버가 버틸 수 있는 적정량을 생성해두고 multi thread로 동작한다.
그럼 Thead pool에 THread가 0개 되면 어떻게 될까?
대기와 거절을 할 수 있다. 우리가 티켓팅할 때 보는 대기열이다.
특징
사용
장점
실무 팁
- WAS의 주요 튜닝 포인트는 max thread 수이다.
- 이 값을 너무 낮게 설정하면
- 동시 요청이 많으면, 서버 리소스는 여유롭지만, 클라이언트는 금방 응답 지연
- 이 값을 너무 높게 설정하면
- 동시 요청이 많으면, CPU, memory 리소스 임계점 초과로 서버 다운
- 장애 발생시
- 클라우드면 일단 서버부터 늘리고, 이후에 튜닝
- 클라우드가 아니면 열심히 튜닝
앞서 cpu가 너무 놀아서도 안되고 너무 바빠서도 안 된다고 하였다. 그럼 Thread pool의 적정 숫자는 어떻게 찾을까?
어플리케이션 로직의 복잡도, CPU, memory, IO 리소스 상황에 따라 모두 다르다.
성능테스트