서블릿

 

*김영한 님의 인프런 강의를 기반으로 정리한 글입니다.

 

form에서 전송한 데이터를 처리할 서버를 직접 구현해야 한다면?

서버 연결대기, 소켓연결, http요청 메세지 파싱, 타입과 url(/save라 가정) 읽기, 바디 내용 파싱, 비즈니스 로직 실행(데이터베이스에 저장 실행), 응답메세지 생성, 응답 전달, 소켓 종료,,,,,,,

하지만 비즈니스 로직 이외에는 다 의미가 없음.. 그저 준비과정일 뿐!

서블릿은 이 준비과정과 응답 과정을 대행해줌

 

@WebServlet(name =”helloServlet”, uslPatterns=”/hello”)\

class~

public void service ~~(HttpServletRequest request, HttpServletResponse response){

로직로직

 

 

 

이렇게 하면 /hello url이 들어오면 이 비즈니스 로직이 실행됨

요청 정보는 request로 매핑이 되고, reponse는 응답정보로 생성되어 제공이 됨.

아주 간단해짐!

http 스팩을 어느정도는 알아야 편리하게 사용이 가능!

 

http요청 시 흐름

was는 request, response 객체를 새로 만들어 서블릿 객체 호출

개발자는 request객체에서 http 요청을 꺼내서 사용 후 response 객체에 http 응답 정보를 입력

was는 response 객체에 담겨있는 내용으로 http 응답 정보를 생성 후 웹 브라우저에 전송!

웹 브라우저가 응답을 렌더링 해 화면에 띄움

 

 

서블릿 컨테이너란?

우리가 만드는 것이 아니고 그냥 호출해서 사용함.

was안에는 서블릿을 지원하는 서블릿 컨테이너가 있음(서블릿을 지원하는 was!)

이 서블릿 컨테이너가 서블릿 객체를 자동으로 생성, 초기화해주고 호출도 해줌.

was가 종료되면 이 서블릿도 같이 종료되는 생명주기도 관리해줌.

싱글톤으로 서블릿을 관리함.(최초 로딩 시점에 서블릿 객체를 만들어두고 재 호출 시 이미 생성한거 재활용. *request response는 매번 새로 만들어야 하지만 컨테이너 자체는 재사용* 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근하게 됨.)

⇒ 공유변수 사용에 주의해야 함.

⇒ 멤버변수가 있으면,, , 다른 사람이 로그인했을 때 타인의 데이터가 보일 수도 있음.

 

jsp도 서블릿으로 변환되어 사용됨.

동시 요청을 위한 멀티 쓰레드 처리 지원 해줌. (여러 사람이 서버에 동시 접속했을 경우)

⇒멀티 쓰레드는 was가 처리하니 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됨.

싱글 쓰레드 프로그래밍하듯 편리하게 소스코드 개발

멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)은 주의해서 사용할 것!

 

 

쓰레드

애플리케이션 코드를 하나하나 순차적으로 실행하는 것 = 쓰레드(main메서드 실행 시 main이라는 쓰레드가 실행 되는 것)

쓰레드는 한번에 하나의 코드라인만 수행함. 즉 동시 처리가 필요하면 쓰레드를 추가로 생성해야 함.

요청이 오면 쓰레드가 할당이 됨. 이 쓰레드를 가지고 서블릿 코드가 실행이 되는 것. 응답까지 끝나면 쓰레드는 다시 휴식.

다중 요청 시 요청 마다 쓰레드를 생성해서 코드를 실행시키는 경우

장점 : 동시 요청 처리 가능. 리소스가 허용될 때까지 처리가 가능함. 하나의 쓰레드 지연 시에도 나머지 쓰레드 정상 동작

단점 : 쓰레드 생성비용이 비쌈(시간). 응답속도가 느려지게 됨. 컨텍스트 스위칭 비용 발생(cpu하나가 쓰레드를 짧게 짧게 전환해서 실행시켜주는거). 쓰레드 생성에 제한이 없어 요청이 너무 많을 경우 cpu나 메모리 임계점을 넘어 서버가 죽어버릴 수 있음.

 

 

 

쓰레드 풀

쓰레드 풀 안에 쓰레드를 미리 만들어 놓고 요청 시마다 풀에 요청해 쓰레드를 배정받음.

쓰레드 사용이 종료 시 쓰레드를 죽이지 않고 풀에 다시 반납.

이런 식으로 돌려가면서 쓰레드를 사용함.

장점 : 풀 안에 있는 쓰레드가 다 사용되고 있으면 추가 요청은 대기하거나 거절하게 됨. 서버가 안죽고 기존 요청을 안전히 처리 가능! 쓰레드가 미리 생성되어 있으니 쓰레드 생성과 종료 비용(cpu)가 절약되고 응답시간이 빠름.

최대 쓰레드 수가 너무 낮으면 서버 리소스는 여유, 클라이언트는 응답 지연이 쉬움

너무 높으면 cpu와 메모리 리소스 임계점 초과로 서버 다운 발생.

장애 발생 시 클라우드면 서버부터 늘리고 쓰레드는 이후 튜닝(일단 서버를 살리긴 해야하니까). 아니면 그냥 튜닝

적정 숫자 찾기 : 로직 복잡도, cpu, 메모리, io리소스 상황에 따라 모두 다름.

최대한 실제 서비스와 유사하게 성능 테스트를 시도해야 함 ( 아파치 ab, 제이미터, nGrinder 등의 툴 사용)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Uploaded by Notion2Tistory v1.1.0