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?
Ainda é prematura a divulgação de números coesos, até porque ainda não fazem 2 dias que implementei tal solução, porém as primeiras impressões são impressionantes!
Usando a extensão YSlow para Firebug (que é uma extensão do Firefox), constatei que a home do VOL tem carregado em 0.7 segundo em horário de pico, o que comparado aos 8, 10 ou até mesmo 16 segundos de antes traz um ganho de pelo menos 8 vezes de velocidade.
Sobre o load da máquina, ele continua o mesmo. Como a velocidade aumentou, existe uma tendência de maior número de impressões de páginas, porém o Light é mais leve que o Apache, então esse aumento de requisições é compensado pelo aumento de leveza do software.
Cada requisição de arquivo corresponde a 1 hit no servidor. Na véspera da implementação da solução, o Apache tratou 1.5 milhão de hits, enquanto que no dia em que passou a trabalhar com o Light, tratou somente 270 mil hits, ou seja, uma carga 5 vezes menor. Enquanto isso o Lighttpd abocanhou 1.3 milhão de hits.
Moral da história: consegui direcionar mais de 80% das requisições do servidor web para o Lighttpd. O Apache ficou somente com o core de processamento, as páginas dinâmicas.
Outro dado importante é com relação às requisições após a implantação da tag Expires (esta já fora adotada a mais tempo). Podemos chutar que, para cada página dinâmica, existem outros 25 arquivos estáticos a serem tratados. Se o VOL envia 270 mil arquivos dinâmicos à seus clientes por dia, teoricamente teria de enviar outros 6.75 milhões de arquivos estáticos, ou seja, teríamos cerca de 7 milhões de hits por DIA. Como a maioria dos clientes já possuem boa parte dos arquivos estáticos armazenados em seus discos locais, os 7 milhões de hits de direito se resumem a 1.5 milhão, santa economia!
E é isso, espero que esse caso de uso traga valor ao seu conhecimento e que te inspire a criar uma solução similar para seu provedor ou empresa.
E desculpem por algum erro de português, uma coisa é revisar o texto dos membros, outra coisa é revisar seu próprio texto, fica muito mais difícil de encontrar os erros quando é você que os comete. :P
[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.