나는 이 글을 읽고 있습니다:
http://www.modrails.com/documentation/Architectural%20overview.html#web_app_models
Phusion Passenger가 Apache2를 확장하여 애플리케이션 서버 역할을 하는 방법에 대해 설명합니다. HTTP 요청이 들어오면 Phusion Passenger 모듈은 Phusion Passenger가 제공하는 애플리케이션에서 해당 요청을 처리해야 하는지 여부를 확인합니다. 그렇다면 모듈은 필요한 경우 애플리케이션에 대한 프로세스를 생성합니다. 요청을 애플리케이션 프로세스에 전달하고 응답을 다시 클라이언트에 전달합니다. 빌드 프로세스를 향상시키기 위해 Passenger는 빌드 서버 역할을 하여 Ruby on Rails 프레임워크 코드와 애플리케이션 코드를 메모리에 캐싱합니다.
이렇게 하면 새 요청이 들어올 때마다 프로세스가 생성될 때 캐시된 코드를 참조하고 프로세스를 빠르게 생성합니다. 그러나 캐시 생성은 http 요청에 비해 여전히 비용이 많이 듭니다. 따라서 응용 프로그램 풀이 사용됩니다. 응용 프로그램 풀이 무엇인지 이해하지 못합니다. 이것이 말하는 내용입니다:
결과 애플리케이션 인스턴스는 활성 상태로 유지되며 해당 핸들은 이 풀에 저장되므로 나중에 각 애플리케이션 인스턴스를 재사용할 수 있습니다. 결과적으로 Passenger는 평균 사례 성능이 매우 우수합니다.
"살아남기"와 "이 풀에 저장된 핸들"은 무엇을 의미합니까? 내 생각에 캐싱은 나중에 데이터를 계속 유지하는 것입니다. 그래서 차이점이 무엇인지 이해하지 못합니다.
답변1
여기에는 바이너리 켜기/끄기 상황이 없습니다. 연속체입니다.
연속체의 한 극단은 오래되었습니다컴퓨터 그래픽 이미지 처리웹 프로그래밍 모델: 웹 서버는 들어오는 각 요청을 처리하기 위해 애플리케이션을 다시 시작합니다. 요청을 처리한 후 애플리케이션이 종료됩니다. 매번 애플리케이션을 다시 시작해야 하기 때문에 다시 빌드해야 합니다.신청현황요청에 따라. 이는 시간과 데이터 공간 모두에서 비용이 많이 듭니다.
따라서 시간이 지남에 따라 비용을 줄이기 위해 많은 옵션이 만들어졌습니다.
빠른 CGICGI 모델을 사용하지만 처음 시작한 후에도 CGI 프로그램을 활성 상태로 유지하고 지속적으로 새로운 요청을 제공합니다. 이렇게 하면 CGI 프로그램을 다시 시작하는 비용을 피할 수 있을 뿐만 아니라 애플리케이션이 RAM에 상태를 저장할 수 있습니다.
mod_{perl,php,ruby,...}실제 애플리케이션 인터프리터를 웹 서버 인스턴스로 가져오는 이러한 시스템은 FastCGI와 동일한 작업을 수행하는 경향이 있습니다. 즉, 각 스크립트를 로드하고 이를 특정 유형으로 컴파일한 후입니다.바이트코드, 모든 작업을 다시 수행할 필요 없이 새로운 요청만 제공합니다.당신이 말하는 시스템은
mod_foo그보다 한 단계 더 높은 시스템으로 전체 애플리케이션의 논리적 모델을 RAM에 유지하므로 각 요청에 대해 다시 생성할 필요가 훨씬 적습니다.mod_foo이것이 당신이 얻는 기본 동작과 정확히 얼마나 다른지 말할 수 없습니다. 하지만 중요한 것은 질적인 차이가 아니라 양적인 차이라는 것입니다.Phusion Passenger의 목표를 이해하는 데 도움이 될 수 있는 다음 단계는 모든 것을 단일 장기 실행 애플리케이션 인스턴스에서 실행하는 것입니다. 이것은 웹 서버 기반 접근 방식입니다.얼랜드일하다,질소와 같은. Apache 기반 애플리케이션의 작동 방식을 비교하려면 두 번째 링크를 방문하세요.
나는 많은 Java 기반 애플리케이션 서버가 동일한 방식으로 작동한다고 생각합니다.
결론은 이 모든 것이 최적화, 속도를 위해 RAM 및 런타임 복잡성을 거래하는 게임이라는 것입니다.
답변2
"keep-alive"라는 용어와 "핸들이 이 풀에 저장되어 있습니다"라는 용어는 캐싱과 다른 것을 의미합니다.
은닉처
캐싱은 검색 비용이 많이 드는 데이터를 나중에 재사용할 수 있도록 빠르게 액세스할 수 있는 위치에 보관하는 메커니즘입니다. 다음과 같은 여러 곳에서 사용되는 것을 볼 수 있습니다.
- 데이터베이스에서 무언가 찾기
- 서버의 IP 주소를 확인하세요.
- 하드 드라이브의 파일에 액세스
풀링
Phusion Passenger 문서에서 "keep Alive"로 언급한 내용은 응용 프로그램을 시작하는 데 걸리는 시간을 절약할 수 있도록 응용 프로그램을 무기한 실행 상태로 유지하는 것입니다.
웹 요청을 처리할 때 애플리케이션이 최대한 응답하기를 원합니다. 애플리케이션을 시작하는 데 몇 초가 걸리고 데이터베이스에서 데이터를 요청하는 데 몇 초가 더 걸리는 경우 반응형 웹 애플리케이션을 만들 수 없습니다.
그래서 우리가 한 일은 연결을 허용하고 애플리케이션의 여러 인스턴스를 항상 실행 상태로 유지하는 경량 프런트엔드를 구축한 다음 프런트엔드가 다음을 수행하는 것입니다.
- 이미 실행 중인 애플리케이션 인스턴스 중 하나에 수신 연결을 할당합니다.
- 이 실행 중인 인스턴스에서 결과 가져오기
- 클라이언트에게 결과를 반환
- 실행 중인 애플리케이션 인스턴스를 다시 "처리 준비 완료" 상태로 전환합니다.
예
나는 여러 금전 등록기가 있는 식료품점의 예를 사용하고 싶습니다. 각 채널은 애플리케이션 서버의 인스턴스이며 각 채널은 한 번에 한 명의 사용자만 처리할 수 있지만 함께 사용하면 여러 사용자에게 서비스를 제공할 수 있습니다.
당신이 보면Ruby용 Mongrel HTTP 서버이는 거의 동일한 방식으로 수영장에서 실행되도록 설계되었습니다.
널리 사용되는 구성 중 하나는 여러 Mongrel 인스턴스와 함께 mod_proxy_balancer를 사용하여 Apache HTTP Server 2.2를 로드 밸런서로 사용하는 것입니다. 각 Mongrel 인스턴스는 mongrel_cluster 관리 유틸리티를 통해 구성된 별도의 TCP 포트에서 실행됩니다. 최근까지 트위터는 이러한 구성의 잘 알려진 예였습니다.
Mongrel은 추가 웹 서버 없이 Ruby on Rails 기반 사이트를 제공할 수 있지만 단일 스레드 애플리케이션으로서 이 구성은 가벼운 로드 외에는 적합하지 않습니다.