Solução que fez com que o desempenho (velocidade de resposta) do servidor web do Viva o Linux aumentasse em até 8 vezes. O Apache2 possui módulos indispensáveis para servir páginas dinâmicas, enquanto o Lighttpd é imbatível quando se trata de páginas estáticas. Então, por quê não combinar os dois?
Ou seja, somente uma entrada no log do Apache, que é o index.php e o restante (conteúdo estático) no log do Light. Note que se você já acessou o site anteriormente, como a tag Expires foi configurada, provavelmente NENHUM log será exibido no arquivo do Light, isso porque seu browser já possui os arquivos e não viu a necessidade de buscá-los novamente no servidor.
[1] Comentário enviado por elgio em 03/09/2009 - 12:00h
Muito bom Fábio.
O legal desta tua solução é a comprovação de que as vezes não basta esta ou aquela solução. Em alguns casos se usa AMBAS. O melhor das duas. Muito bom.
[4] Comentário enviado por TheHawk em 03/09/2009 - 13:13h
Geralmente não comento muito aqui no VOL..... mas essa aqui eu fiz questão de deixar o comentario.... tá de parabens.... muito boa solução, otimizou bem o negocio.... trabalho com provedor wireless e aqui estou usando o ThunderCache, quando estava usando o apache para servidor os arquivos para o thunder estava tendo uma lentidão terrivel.... depois de mudar o servidor web parea o lighttpd foi dá agua para o vinho, extremamente rapido e leve.... o light é otimo...... mais uma vez parabens pela solução, até mais.
[6] Comentário enviado por cleberjsantos em 03/09/2009 - 13:59h
Opa Fábio,
Boa.... ;) E então, eu estava testando o Light também, mas me deparei com alguns problemas, talvez por ainda não o conhecer diretamente claro! Mas a idéia era basicamente abandonar o Apache e partir para a combinação Lighttpd + Varnish, hoje uso Apache + Varnish, no qual já dá um adianto tremendo, então imagina o Light + Varnish ;)
Bem, vou documentar minha experiência, e com base nela fazer um How-to aqui também, neste caso estou falando de usar Zope/Plone com Light + Varnish, se depois desejar podemos trocar figurinhas quanto a otimizações ;)
[7] Comentário enviado por foguinho.peruca em 03/09/2009 - 18:09h
Olá!
Boa solução! Vou tentar implementar uma semalhante, porém eu o uso a combinação do tomcat (para o java) + apache (redirecionamento na rede). acho que vou dividir a carga do tomcat com o lighttpd e ver no que da... ^^''
[9] Comentário enviado por isaque_alves em 03/09/2009 - 23:09h
Cara, essa solução é perfeita...
vo testar assim que chegar em casa no meu servidor de testes e demonstações...
valeu por compartilhar o conhecimento!!
E é isso!!
[16] Comentário enviado por removido em 09/09/2009 - 20:31h
Boa noite.
Fábio, você poderia corrigir o exemplo de integração do Apache com Lighttpd na 'Versão para impressora'. O exemplo de configuração para integrar os dois Web Server é exibido da seguinte forma:
[18] Comentário enviado por removido em 20/11/2009 - 15:59h
Fabio,
Estou com a seguinte situação e gostaria de uma opinião sua.
o hardware é o seguinte.
DELL 1950
2 processadores quadcore e 8gb de RAM
2 discos SAS em RAID 1
o sistema que esta hospedado nele é TOMCAT e POSTGRES 8.3. O Load average dele é de uma média de 3.5 a 4, tenho uma média de 250 conexões simultãneas e acho que esta ficando cada vez mais lento.
Tentei uma solução de proxy reverso com o apache mais a aplicação fica com problemas no jsession, ai vem a minha pergunta se eu colocasse o lighttpd na frente junto com o apache para separar o conteudo statico melhoraria????
[24] Comentário enviado por elderjmp em 30/08/2010 - 00:12h
Fábio,
Parabéns pelo artigo, muito bom.
Pq usar o mod_proxy do Apache para direcionar as requisições de conteúdo estático ao invés de requisitar diretamente ao Lighttpd, passando o caminho na porta 81, no arquivo index.php (<img src="http://img.vivaolinux.com.br:81/imagens/logotipo01.png">)?
E usando o Debian aqui, ocorreu o erro "client denied by server configuration: proxy:http://...". O mod_proxy só funcionou depois de habilitar no arquivo /etc/apache2/mods-available/proxy.conf a diretiva "Allow from all" (Default é "Deny for all"). Algum problema em permitir para todos?
[25] Comentário enviado por fabio em 30/08/2010 - 00:34h
Olá Elder,
Passar o caminho diretamente no código-fonte ao invés de usar o mod_proxy é viável quando seu site é composto por apenas alguns arquivos, mas no caso do VOL, ele possui milhares de links, então é mais fácil alterar somente o apache.conf a centenas de arquivos.
O allow from all é tranquilo de usar, mas sugiro que dê um options -indexes para evitar que possam acessar a lista de arquivos dos diretórios.
[26] Comentário enviado por julianjedi em 16/09/2010 - 13:02h
Nossa .. muito bom mesmo fabio, quando li no excerpt do artigo pensei ateh q vc ia fazer um monte de remendo ... mas ficou muito simples de entender e os resultados foram sensacionais ... com certeza é uma grande contribuição para a comunidade...
[27] Comentário enviado por dolivervl em 08/10/2010 - 23:57h
Fábio uma coisa que quero saber de vc é o seguinte, compactação com o apache, já usou ? qual sua opnião sobre isso? Uso no proxy onde trabalho e reduziou e muito o consumo de banda e não aumento consideravelmente o uso de CPU do servidor proxy.
[32] Comentário enviado por ederrb em 06/05/2011 - 11:17h
Fábio(e quem mais puder ajudar), tenho exatamente essa máquina: Intel Xeon E3110 Woldfale (2 cores x 3.0 GHz), 8GB Ram e 1,5TB de disco. Nessa maquina rodo um servidor de armazenamento de áudio(tal como o 4shared) sendo que com algumas implementações a mais e alguns diferenciais(vide www.suamusica.com.br ). Na hora do pico chega a ter mais de 200 downloads simultaneos. Estes downloads são feitos através de readfile() no php(principalmente para que os visitantes não tenham conhecimento sobre o caminho dos arquivos p/ download). Isso deixa a máquina arrastando-se, já cheguei a registrar load de 95 e a solução que vi foi reiniciar o httpd acarretando na perda de todas as conexões, caso eu não restarte o httpd a maquina trava geral. Ouvi dizer que o lighthttpd tem uma extensão X-LIGHTTPD-send-file que dispensaria o uso de readfile(), assim o php nao faria o trabalho de "soltar o download na tela" e pelo que vejo nos processos é justamente ele quem está consumindo todo o hardware da maquina. Pela sua experiência, seria viável instalar o lighthttpd com essa configuração passada por você + essa extensão? Tentei usar a extensão na minha configuração atual com apache mas nao obtive êxito. Desculpe-me pelo texto demasiado longo, vi aqui uma oportunidade de resolver este problema que vem persistindo há quase um mes. Agradeço desde já ! Abraços.