서블릿에 대해서 알기 전에 웹 동작 흐름에 대해서 알고 가자.
클라이언트가 HTTP 형식으로 Web Server로 요청을 보내면 웹 서버는 이 요청을 풀어 HTML, CSS, JS를 처리해 준다. 애플리케이션 로직과 같은 동적인 처리가 필요하면 Web Server는 WAS에게 요청을 보낸다. WAS는 요청을 받아서 애플리케이션 로직을 처리하고 Web Server로 응답을 넘겨주고 Web Server는 클라이언트의 요청에 대한 응답을 넘겨준다.
WAS는 동적기능을 포함하여 웹서버 기능을 포함하고 있어서 웹서버 없이 클라이언트, WAS 만으로 시스템 구성이 가능하다. 하지만 이렇게 된다면 WAS가 너무 많은 역할을 담당하여 서버에 과부하가 올 확률이 높다. 따라서 웹서버와 WAS를 같이 쓰는 웹 시스템 구성이 제일 많이 선호된다.
이 과정에서 클라이언트가 보내는 요청을 웹 서버가 읽어들이는데 사용 되는 것이 서블릿이다.
웹 어플리케이션 서버를 우리가 직접 구현해야 한다면 우리는 다음과 같은 업무를 모두 처리해야 한다.
사실 여기서 제일 중요한 로직은 username과 age를 가져와 회원을 저장하는 것이지만 이것을 수행하기 전에 해야하는 단계들이 너무 많다. 이를 해결하고자 의미있는 비즈니스 로직을 제외한 모든 작업들을 지원해 주는 것이 서블릿이다.
@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
@Override
protected void service(HttpServletRequest request, HttpServletResponse response){
//애플리케이션 로직
}
}
이를 활용하여 개발자는 HTTP 스펙을 편리하게 사용한다.
❓ Context Switching:
CPU/코어에서 실행 중이던 프로세스/스레드가 다른 프로세스/스레드로 교체되는 것
WAS를 사용할때 주요 튜닝 포인트는 쓰레드 풀에서 설정하는 최대 쓰레드 수이다. 이를 너무 높게 설정하면 서버가 다운될 수 있고 너무 낮게 설정하면 클라이언트 응답 지연이 많아진다. 따라서 애플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라서 쓰레드들 적정하게 맞춰야 한다.