☰

Apache에 비해 Lighttpd의 또 다른 이점

tag-icon • tag-icon apache-2.2 performance lighttpd latency
Apache에 비해 Lighttpd의 또 다른 이점

Apache 앞에 Lighttpd를 사용하는 것의 또 다른 이점은 하위 프로세스 수가 적다는 사이트를 읽었습니다. Lighttpd는 Lighttpd와 Apache 간의 대기 시간이 매우 짧기 때문에 Apache의 하위 프로세스가 동적 페이지를 더 빠르게 제공하는 동안 연결 유지 및 클라이언트 요청을 처리합니다. 링크를 찾으려고 하는데 어렵네요.

정적 콘텐츠(img, vid, css, js, html 등)를 위한 전용 Lighttpd 서버와 동적 페이지(php)를 위한 또 다른 전용 Apache 서버가 이미 있다는 점을 고려하면, 실제로 이 기술을 구현하고 싶습니다. 약간의 성능 향상이 있습니다.

1) 위에서 설명한 것과 같은 목적으로 Apache 앞에 Lighttpd를 설치한 사람이 있습니까?
2) 실제로 성능이 향상됩니까? 얼마나 많이?
3) Apache에 대한 요청을 처리하는 Lighttpd의 오버헤드는 어떻습니까? 정말 그만한 가치가 있습니까?

감사해요!

답변1

  1. 우리는 정적 콘텐츠를 가볍게 제공하고 동일한 서버의 Apache에 동적 요청을 전달했지만 다른 포트에서 수신 대기했습니다.
  2. "동적을 위해 Apache로 전달"은 성능 목적으로 수행된 것이 아니라 클라이언트 지점에서 단일 서버를 보유하여 모든 것을 서비스하기 위해 수행되었습니다. 그러나 Apache에 대한 과도한 연결을 피할 수 있다면 이는 좋은 부수적 이점입니다. 더 많은 연결 = 더 많은 프로세스 = 더 많은 메모리(특히 mod_php의 경우). 숫자는 없습니다. 죄송합니다.
  3. Apache라는 돼지에 비해 오버 헤드가 무시하는 것처럼 보였습니다.

즉, 프런트엔드로 가벼운 대신(또는 그 앞에) Varnish 리버스 프록시를 고려해야 합니다. 매우 빠르고 효율적입니다. 동적 페이지(또는 ESI를 사용하는 페이지 조각)를 캐싱할 때 특히 흥미롭습니다. 이는 백엔드 로드를 줄이고 트래픽 급증을 흡수하는 데 도움이 됩니다.

그리고 Apache 대신 nginx(PHP-FCGI 포함)를 백엔드로 사용할 수도 있습니다(Varnish 프런트엔드를 추가하는 것보다 더 복잡한 작업이지만)(nginx도 프런트엔드로 사용할 수 있지만 다음과 같은 전용 역방향 프록시만큼 좋지는 않습니다). 광택). 면책조항: 저는 nginx 경험이 없습니다. ;)

답변2

나는 아파치의 부하를 줄이기 위해 아파치 옆에 lighttpd를 고소하는 것과 같은 상황에 처해 있었습니다.

리소스가 덜 필요하므로 가벼운 웹 서버로 정적 콘텐츠를 제공하는 것이 더 좋습니다. 또한 PHP는 아파치를 사전 포크 모드에서 실행해야 하며, 이로 인해 아파치가 효율적으로 실행되지 않는다는 점도 언급해야 합니다. 서로 다르게 설정된 두 개의 웹 서버에 로드를 분산할 수 있으며, 각각은 가장 적합한 트래픽을 처리합니다.

일부 구현 참고 사항:

세 가지 옵션이 있습니다:

  1. IP 계층에서 코드 및 세그먼트 트래픽을 수정하십시오.
  2. 애플리케이션(http) 계층에서 코드 및 세그먼트 트래픽을 수정하지 마십시오.
  3. 실제 서비스 제공을 위해 웹 서버 중 하나가 다른 웹 서버로 들어오는 요청을 전달하도록 합니다.

첫 번째는 더 빠르고, 두 번째는 구성이 덜 필요하며, 세 번째는 노새와 같습니다.

제가 당신이라면 세 번째 옵션은 고려하지 않을 것입니다. 왜냐하면 구성 악몽이 따르기 때문입니다. 또한 첫 번째 웹 서버에서 무언가를 잘못 구성하면 아무 것도 작동하지 않으며 문제가 있는 곳을 찾아내기가 더 어렵습니다.

예전에는 해결책이 급히 필요해서 옵션 2를 선택했고, 역방향 프록시라는 것을 활용했습니다.파운드정적/동적 콘텐츠에 대한 요청을 분할하고 두 개의 서로 다른 웹 서버에 로드를 분산합니다.

작동하기는 하지만 http 콘텐츠를 적극적으로 모니터링해야 하므로 성능에 큰 타격을 줍니다(추가 데몬 실행).

옵션 2를 사용하면 정적 콘텐츠(static.domain.org)에 추가 IP를 활용하여 더 나은 성능을 얻을 수 있으며 클라이언트가 콘텐츠에 대해 이 static.domain.org를 참조하도록 할 수 있습니다. 여전히 역방향 프록시가 필요하지만 프록시는 요청에서 Host: 헤더를 확인할 필요가 없으므로 더 빠릅니다.

다음은 참조용 파운드 구성 스니펫입니다.

ListenHTTP 
        Address 195.175.71.17
        Port 80
        Client 30
        RewriteLocation 2

        Service
                HeadRequire "^[Hh]ost:\s*www.nasa.gov$"
                URL "^/static/content"
                BackEnd
                        Address 127.0.0.1
                        Port 81
                        TimeOut 300
                End
        End
        Service
                HeadRequire "^[Hh]ost:\s*www.nasa.gov$"
                BackEnd
                        Address 127.0.0.1
                        Port 80
                        TimeOut 300
                End
        End
ListenHTTP

관련 정보