▶ 동적 컨텐츠를 반환하는 웹 서버(AP 서버) 에는 애플리케이션이 이용하는 프로그램을 메모리에 상주시킴으로써, 애플리케이션 기동시의 오버헤드를 피하게 설계되어있다. 자바로 작성된 프로그램은 일단 기동할떄에는 상당한 시간이 소요되지만 한번 메모리에 올라가 상주하게 되면 이후느 기동시간이 줄어드는
것을 알수가 있다. mod_perl 이나 mod_php로 펄 이나 PHP를 웹 서버에 내장해서 이용한다면 애플리케이션에서의 처리가
빨라지게 되는 것도 같은 원리이다. 또한 FastCGI도 거의 같은 원리로 애플리케이션의 속도를 향상시켜준다.
웹 서버는 이런 상황에서 대량의 메모리를 소요하게된다. 정적 콘텐츠만을 반환하는 웹 서버에 비해 동적 콘텐츠를 반환하는 웹 서버는 수배에서 수십배의 메모리를 소비하는 경우도 많다.
보통 웹 서버는 클라이언트 하나의 요청에 대해 하나의 프로세서ㅡ 또는 하나의 쓰레드를 할당 해 서 처리하는 방식을 취하고 있다. 각각의
프로세스 / 스레드는 다른 프로세스/스레드와는 독립적으 로 동작한다. 이로 인해 애플리케이션 개발자는 리소스 경합을 신경쓰지 않고
프로그램을 개발 할 수 있으므로, 애플리케이션 설계가 쉽고 편해진다는 장점을 얻을 수 있다.
그러나 웹 서버가
하나의 요청에 대해 하나의 프로세스/스레드로 응답할 경우, 이미지나 자바스크 립트, CSS와 같은 정적콘텐츠를 반환하는, 즉 파일에
쓰인 내용을 그대로 반환하기만 하면 될 경우 에도 동일한 방식으로 리소스를 반환하게 된다.
예를 들면, 동적으로 생성된 하나의 HTML 페이지 내에 이미지가 30개 정도 사용되고 있는 경우 를 따져보자. 만약 NAVER 의 메인페이지와 같은 페이지다, 이 페이지는 동적으로 생성되고 있다. 이
페이지에 대한 요청은 첫 요청 한 번만 동적 콘텐츠를 요구하게 된다. 첫 요청 으로 HTML 이 동적으로 생성되고, 이 HTML
은 클라이언트인 브라우저에 의해 다운로드 된다. 다음으로 브라우 저는 HTML 을 해석해서 필요한 이미지 파일이나 스크립트 파일을
서버에 요청하 게 된다. 결국에는 최초 동적 요청 1번에 나머지 정적 요청 30번이 되는것이다.
▶ 모두 웹 서버에서 응답할 경우 아까처럼 1 + 30 회의 요청을 모두 웹 서버에서 응답할 경우, 전체적으론느 정적 콘텐츠를 반환 하는 게 주된 일이지만 최초 1회
요청을 처리할 뿐임에도 나머지 30회의 정적인 요청에 대해 응답 할 떄에도 대량으로 메모리를 소비하게 된다. 이는 이미지든 동적
콘텐츠든 똑같이 하나의 요청에 대해 하나의 프로세스/스레드로 음답할 필요가 있기 때문이다.
▶ 서버를 분할할 경우 정적인 파일을 변환하는 웹 서버와 동적 콘텐츠를 생성하는 웹 서버를 각기 다른 서버로 나누게 될 경우 정적 콘텐츠는 메모리 소비량이
적은 웹 서버가 응답하고 동적 콘텐츠만 애플리케이션으로 응답하는 형태의 구성이 가능해진다. 시스템 전체적으로 메모리 사용 효율이
높아져서 동시 처리 할 수 있는 요청수도 향상된다.
- 요청된 URL 이 이미지 파일이거나 CSS 같은 스크립트 언어라면 정적 Content 서버로 - 그 밖에 동영상이나 플래시등의 요청이라면 동적 Content 서버로
- 이와 같이 URL의 내용을 보고 요청을 할당할 곳을 변경한다. 리버스 프록시의 이 같은 동작은 L7 스위치에 상당하는 처리를 수행하는 것으로 볼 수 있다. - 이 떄, 리버스 프록시 자신도 웹 서버라는 특징을 살려서 정적 콘텐츠는 리버스 프록시 자신이 반환하는 형태의 구성이 보통의 구성적인 방법이다.
