이미 2 가지 좋은 답변이 있지만 아마도 가장 중요한 실제 문제 는 아직 언급되지 않았습니다.

먼저 OP는 2 개의 이전 답변 과이 작은 블로그 게시물 을 읽고 Keepalives가 무엇인지 이해할 수 있습니다. (저자는 TCPI / IP가 연결이 더 길어질수록 “빠르게”되는 부분에 대해 자세히 설명하지 않습니다. 사실, 오래 지속되는 연결은 IP 창 크기 조정의 이점이 있지만 파일이 없으면 그 효과는 중요하지 않습니다. 또는 지연 지연 제품이 비정상적으로 큰 경우)

Apache를 사용할 때 HTTP Keepalive에 대한 큰 주장 은 Apache 프로세스를 차단한다는 것입니다. 즉, keepalives를 사용하는 클라이언트는 클라이언트가 연결을 닫거나 시간 초과에 도달 할 때까지 ‘his’Apache 프로세스가 다른 클라이언트를 처리하지 못하게합니다. 같은 기간 동안이 Apache 인스턴스는 다른 많은 연결을 제공 할 수있었습니다.

이제 매우 일반적인 Apache 구성은 Prefork MPM 과 PHP / Perl / Python 인터프리터 및 언급 된 언어의 애플리케이션 코드입니다. 이 경우 각 Apache 프로세스는 수 메가 바이트의 RAM (인터프리터 및 애플리케이션 코드와 연결된 Apache)을 차지한다는 의미에서 “무거운”것입니다. 이것은 각 keepalive’d Apache 인스턴스의 차단과 함께 비효율적입니다.

일반적인 해결 방법 은 서로 다른 구성으로 2 개의 Apache 서버 (동일한 물리적 서버 또는 2 개의 서버)를 사용하는 것입니다.

• 동적 콘텐츠에 대해 mod_php (또는 프로그래밍 언어가 사용되는)가있는 “무거운”하나는 keepalives가 꺼져 있습니다.
• 정적 콘텐츠 (이미지, css, js 등)를 제공하기 위해 최소한의 모듈 세트가있는 하나의 “경량”, keepalives가 켜져 있습니다.

그런 다음 필요에 따라 이러한 동적 및 정적 컨텐츠 분리를 확장 할 수 있습니다 ( 예 :

• 같은 정적 콘텐츠에 대한 이벤트 기반의 서버를 사용 Nginx에 .
• 정적 컨텐츠에 CDN 사용 (모든 정적 컨텐츠를 처리 할 수 ​​있음)
• 정적 및 / 또는 동적 컨텐츠의 캐싱 구현

Apache 차단을 피하는 또 다른 방법 은 Perlbal 과 같은보다 스마트 한 연결 처리 기능을 갖춘로드 밸런서를 사용하는 것 입니다.

.. 그리고 훨씬 더. 🙂

답변