Outro benefício do Lighttpd na frente do Apache

Question

Eu li em um site que outro benefício de ter o Lighttpd na frente do Apache é menor número de processos filhos. O Lighttpd lidará com as solicitações keep-alive e do cliente, enquanto os processos filhos do Apache conseguem atender páginas dinâmicas mais rapidamente, devido à comunicação de latência muito baixa entre o Lighttpd e o Apache. Estou tentando encontrar o link, mas estou com dificuldades.

Dado que eu já tenho um servidor Lighttpd dedicado para meu conteúdo estático (img, vid, css, js, html, etc.) e outro servidor Apache dedicado para minhas páginas dinâmicas (php), eu gostaria de implementar essa técnica se realmente tem algum ganho de desempenho.

1) Alguém colocou um Lighttpd na frente do Apache para o mesmo propósito explicado acima?
2) Existe realmente um ganho de desempenho nisso? Quanto custa?
3) E sobre a sobrecarga do Lighttpd lidando com o pedido do Apache? Vale a pena?

Obrigado!

    

Answer 1

1. Tivemos conteúdo servindo lighty e encaminhamos as solicitações dinâmicas para o Apache no mesmo servidor, mas ouvindo em outra porta
2. o "encaminhar para o apache para dinâmico" não foi feito para fins de desempenho, mas apenas para ter um único servidor a partir do ponto do cliente, servindo tudo. No entanto, se você puder evitar o excesso de conexões com o Apache, é um bom benefício colateral. Mais conexões = mais processos = mais memória (especialmente com mod_php). Então, sem números, desculpe.
3. a sobrecarga parecia negligente em comparação com o porco que é o Apache

Dito isto, você deve considerar o proxy reverso Varnish em vez de (ou na frente de) lighty como seu frontend. É muito rápido e eficiente. Especialmente interessante para cachear páginas dinâmicas (ou fragmentos de páginas, usando ESI), ajuda a reduzir a carga de back-end e a absorver os picos de tráfego.

E possivelmente use o nginx (com PHP-FCGI) como backend em vez do Apache (embora seja uma tarefa mais complicada do que adicionar um frontend do Varnish) (o nginx também pode ser usado como frontend, mas não é tão bom proxy reverso como o verniz). Disclaimer: Eu não tenho experiência nginx;)

    

Answer 2

Eu costumava estar na mesma situação, processando o lighttpd ao lado do apache) para reduzir a carga no apache.

É melhor fornecer conteúdo estático com um servidor da Web leve, pois isso exige menos recursos. Também é preciso mencionar que o PHP requer que o apache seja executado no modo pré-bifurcado, o que desativa a execução eficiente do apache. Você pode distribuir a carga para dois servidores da web configurados de maneira diferente, cada um manipulando o tráfego da melhor forma.

Algumas notas de implementação:

Você tem três opções:

1. modifique seu código e segmente o tráfego na camada IP
2. não modifique seu código e segmente o tráfego na camada de aplicativo (http)
3. obtenha um dos servidores da web para transmitir solicitações que chegam ao outro servidor da web para veiculação real

O primeiro é mais rápido, o segundo requer menos configuração, o terceiro é como uma mula.

Eu não consideraria a terceira opção se eu fosse você, já que ela vem com um pesadelo de configuração; também, se você configurar algo incorretamente no primeiro servidor web, nada funcionará e será mais difícil identificar onde está o problema.

No passado, eu precisava ter uma solução urgentemente, então fui com a opção 2 e usei um proxy reverso chamado pound segmentar solicitações em conteúdo estático / dinâmico e distribuir a carga para os dois servidores da web diferentes.

Embora funcione, é necessário monitorar ativamente o conteúdo http, o que prejudica o desempenho (um daemon extra em execução).

Com a opção 2, você pode obter um melhor desempenho com a utilização de um IP extra para conteúdo estático (static.domain.org) e fazer com que os clientes consultem este static.domain.org para o conteúdo. Ele ainda exigirá um proxy reverso, mas o proxy não precisa verificar o cabeçalho Host: em qualquer um dos pedidos, então será mais rápido.

aqui está um trecho de configuração da libra para sua referência:

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