Otimizando seu web server com Apache2 + Lighttpd

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?

[ Hits: 103.011 ]

Por: Fábio Berbert de Paula em 03/09/2009 | Blog: https://fabio.automatizando.dev


Integrando Apache2 com Lighttpd



O módulo do Apache responsável pela integração entre os 2 serviços é o proxy_http, que por sua vez depende do proxy. Então temos que verificar se ambos estão habilitados no Apache.

O comando a2dismod é usado para desabilitar um módulo ativo do Apache, quando executado sem parâmetros ele mostra a lista dos módulos ativos. Então vamos usá-lo para descobrir quais módulos estão ativos no momento (o que nos interessa é saber se proxy e proxy_http estão ativos ou não):

# a2dismod
Your choices are: alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi dir env expires headers include mime negotiation php5 rewrite setenvif ssl status suexec z_dir
Which module(s) do you want to disable (wildcards ok)?

Pressione Ctrl + C para cancelar a operação.

Os módulos que precisamos habilitar são o proxy e proxy_http. Se eles não tiverem listados na saída do comando acima, precisamos habilitá-los com o a2enmod:

# a2enmod
Your choices are: actions alias asis auth_basic auth_digest authn_alias authn_anon authn_dbd authn_dbm authn_default authn_file authnz_ldap authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cern_meta cgi cgid charset_lite dav dav_fs dav_lock dbd deflate dir disk_cache dump_io env expires ext_filter file_cache filter headers ident imagemap include info ldap log_forensic mem_cache mime mime_magic negotiation php5 proxy proxy_ajp proxy_balancer proxy_connect proxy_ftp proxy_http rewrite setenvif speling ssl status substitute suexec unique_id userdir usertrack version vhost_alias Which module(s) do you want to enable (wildcards ok)?
proxy proxy_http

Pronto, módulos habilitados!

NOTA: Os comandos a2dismod e a2enmod são utilitários providos pelo Debian visando a facilitação do gerenciamento de módulos do Apache. Caso eles não existam em sua distribuição, procure saber como fazer na mão. Tu é nerd, sabe se virar! :)

Configurando o Apache

Agora que temos os módulos de proxy habilitados, vamos configurar o virtualhost do site desejado para direcionar as requisições de conteúdo estático para o Light.

Solução 1

No meu caso, os diretórios que possuem conteúdo estático são:
  • /imagens
  • /css
  • /js
  • e alguns outros, mas vou usar somente esses para resumir a configuração.

Então editando o arquivo de configuração do virtualhost, que no meu caso é /etc/apache2/sites-enabled/vivaolinux.com.br:

# vim /etc/apache2/sites-enabled/vivaolinux.com.br

Faremos:

<VirtualHost www.vivaolinux.com.br>

        ProxyPass /imagens/ http://www.vivaolinux.com.br:81/imagens/
        ProxyPassReverse /imagens http://www.vivaolinux.com.br:81/imagens
        ProxyPass /css/ http://www.vivaolinux.com.br:81/css/
        ProxyPassReverse /css http://www.vivaolinux.com.br:81/css
        ProxyPass /js/ http://www.vivaolinux.com.br:81/js/
        ProxyPassReverse /js http://www.vivaolinux.com.br:81/js
        ProxyPreserveHost on

        ... resto da conf. omitida ...

</VirtualHost>

Ou seja, adicionei as linhas de configuração de proxy no início do virtualhost para evitar que os caminhos sejam tratados por qualquer outro módulo ou parâmetro. Note que para cada diretório foram criadas duas entradas, ProxyPass e ProxyPassReverse, o primeiro com / no final do path e o segundo sem. O que essas linhas fazem é redirecionar a requisição nos diretórios acima para a porta 81 do servidor, que roda o Lighttpd.

Solução 2

A solução 1 possui uma desvantagem. As requisições de arquivos, mesmo sendo tratadas somente pelo Light, são logadas tanto no Apache quanto no Light, o que gera uma duplicação de logs e consequente maior consumo de espaço em disco e I/O.

Na verdade o que fiz foi a combinação da solução 1 e 2. Esta segunda solução trata da criação de um virtualhost exclusivo para conteúdo estático, ou seja, todas as imagens, arquivos css e js serão carregados pelo host img.vivaolinux.com.br ao invés do tradicional www.vivaolinux.com.br.

Para tal basta criar um novo virtualhost com a seguinte configuração:

# vim /etc/apache2/sites-enabled/vivaolinux.com.br

(adicionar o novo virtualhost no final do arquivo)

<VirtualHost img.vivaolinux.com.br>
  ServerName img.vivaolinux.com.br
  ServerAlias img.vivaolinux.com.br

  ProxyPass / http://img.vivaolinux.com.br:81/
  ProxyPassReverse / http://img.vivaolinux.com.br:81
  ProxyPreserveHost on
</VirtualHost>

Ou seja, o virtualhost se resume a redirecionar TUDO de img.vivaolinux.com.br para o Lighttpd.

NOTA: Não se esqueça que é preciso criar o host no servidor de DNS, senão não funciona né!? :P

Mas, nem tudo são rosas, para que esta solução funcione você precisa varrer TODOS os arquivos html do seu site e mudar as ocorrências de:

<img src="/imagens/logotipo01.png">

Para:

<img src="http://img.vivaolinux.com.br/imagens/logotipo01.png">

Convertendo a situação acima para um padrão a se usar com expressão regular, ficaria de:

src="/imagens

Para:

src="http://img.vivaolinux.com.br/imagens

Para automatizar esta tarefa usei o script em Perl substituir.pl.

Faça um backup de seus arquivos HTML e em seguida execute, na raiz do seu diretório web:

$ ./substituir.pl 'src=..imagens' 'src=\"http:\/\/img.vivaolinux.com.br\/imagens' `find . -name "*.html"`
Substituindo todas as ocorrências de
"src=..imagens" para "src=\"http:\/\/img.vivaolinux.com.br\/imagens"...

Processando teste.html...
... [ OK ]

Substitua os parâmetros acima para os que são válidos para o seu site. O script varrerá todos os seus arquivos html e adaptará as tags de carregamento de imagem de /imagens para http://img.vivaolinux.com.br/imagens.

Este foi só um exemplo de padrão identificado, caso você possua outros padrões de link para conteúdo estático, tal como carregamento de arquivos CSS, JavaScript e até mesmo outros diretórios de imagens, repita o procedimento até chegar ao resultado desejado.

Por fim, caso não tenha entendido bulufas da solução 2, acho melhor se concentrar somente na solução 1. :)

Configurando Expires no Apache

Para modificar a tag Expires no Apache precisamos primeiro habilitar o módulo "expires":

# a2enmod expires

Em seguida edite seu virtualhost adicionando a seguinte configuração:

        ExpiresActive On
        <FilesMatch "\.(gif|jpg|jpeg|png|css|js|swf|GIF|JPG|JPEG|PNG|txt|TXT)$">
                ExpiresDefault "access plus 1 year"
        </FilesMatch>

Note que aqui há um exagero. Se nosso conteúdo estático já está sendo provido pelo Lighttpd e o mesmo já possui a tag Expires habilitada, pra quê habilitar isso também no Apache?

Pois é, neste caso não é necessário, porém como promessa é dívida, eis a forma de configurá-la no Apache. E além disso, caso você esteja lendo esse artigo por curiosidade e não ache necessário instalar o Light, pelo menos otimizar o seu cache pelo índio você pode fazer né? Larga de ser administrador relaxado!

Finalizadas as configurações, vamos reiniciar o Apache:

# /etc/init.d/apache2 restart

NOTA: Se você sabe como configurar o mod_proxy em conjunto com a diretiva <FilesMatch>, a solução ficará bem mais simples. Para isso basta criar um filtro com as extensões de arquivos estáticos e direcioná-las para o proxy. Então se sabe como fazer, deixe-nos tomar conhecimento através de um artigo ou comentando neste.

Página anterior     Próxima página

Páginas do artigo
   1. Considerações iniciais
   2. Apache2 vs Lighttpd
   3. Controle de cache no cliente: tags expires e etag
   4. Instalando e configurando o Lighttpd
   5. Integrando Apache2 com Lighttpd
   6. Testando a configuração
   7. Resultados e conclusão
Outros artigos deste autor

Criando gráficos com a classe JPGraph (parte 1)

Como fazer publicações pelo Instagram Web

Criando um painel de rede em PHP

Tradutor de palavras em vários idiomas via shell

Zello - Transforme seu Android (e GNU/Linux) num Walkie Talkie

Leitura recomendada

Instalando Wireless USB Adapter D-Link DWL-G122 no Debian

Instalação completa do CACIC no Slackware 12.2

Compartilhando arquivos e bookmarks do Firefox entre Linux e Windows

Recupere o Grub na MBR após uma instalação do Windows

Instalando placa wireless Intel 3945ABG no Debian

  
Comentários
[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.

[2] Comentário enviado por marcelomortificy em 03/09/2009 - 12:11h

Muito bom!!!!


Parabéns Fábio.

[3] Comentário enviado por marcelomendes em 03/09/2009 - 12:15h

Muito bom Fábio, parabéns!

[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.

[5] Comentário enviado por cesar em 03/09/2009 - 13:45h

Boa!

[]'s

[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 ;)

Cleber J Santos
www.cleberjsantos.com.br

[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... ^^''

Jeff

[8] Comentário enviado por removido em 03/09/2009 - 21:03h

Parabéns chefito.... Será que seu trabalho vai ganhar uma camiseta redbul ?????
rs...rs...rs...rs...

[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!!

Viva o Software Livre!!!
Viva o Linux!!

[10] Comentário enviado por maran em 04/09/2009 - 12:30h

Show!

[11] Comentário enviado por junior em 04/09/2009 - 15:55h

Já dizia o poeta: Fodástico!

[12] Comentário enviado por pinduvoz em 04/09/2009 - 21:30h

O site realmente ganhou agilidade.

Parabéns!

[13] Comentário enviado por pedro-filho em 06/09/2009 - 02:56h

tem como configurar o expires no squid ?????

obrigado....

[14] Comentário enviado por reideer em 07/09/2009 - 21:40h

Boa noite.
Eu já testei esta solução a algum tempo, porém precisava de virtualhosts e mais algumas coisas, no final das contas se tornou inviável.

Gostaria de Saber se o Vol utiliza algum sistema de Cache, e qual?

[15] Comentário enviado por franciscosouza em 09/09/2009 - 08:16h

Sensacional, parabéns pelo artigo! ;D

[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:

<img src="http://img.vivaolinux.com.br/imagens/logotipo01.png">
Para:
<img src="http://img.vivaolinux.com.br/imagens/logotipo01.png">

Deveria ser:

<img src="/imagens/logotipo01.png">
Para:
<img src="http://img.vivaolinux.com.br/imagens/logotipo01.png">



[17] Comentário enviado por guilhermecunha em 10/09/2009 - 08:43h

Muito legal, concerteza me lembrarei deste artigo quando administrar um site com muitos acessos...

Abraço!

Guilherme Cunha
http://www.guilhermecunha.com.br

[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????

abraços

Filipe Mendonça

[19] Comentário enviado por removido em 20/11/2009 - 20:25h

Ótimo artigo Fábio.
Intressante essa implementação para o site.

[]'s

[20] Comentário enviado por fabio em 21/11/2009 - 22:26h

Olá Filipe,

No caso você não precisaria do Apache, apenas o Lighttpd com Tomcat.

Alguma processo está pesando demais aí, essa máquina não pode ter 3/4 de load com apenas 250 acessos simultâneos.

PS: O Tomcat por natureza é lento e consome muito hardware, pelo menos era assim quando o utilizei a 4 ou 5 anos atrás, não sei como é agora.

Um abraço.

[21] Comentário enviado por Holmes em 16/12/2009 - 22:08h

muito interessante, vlw, Placebo..............gostei das informações...........

[22] Comentário enviado por ferreirajr630 em 26/01/2010 - 09:14h

Paraben otimo mas otimo mesmo esse artigo esparo que venha mas artigos na mesma categoria de melhoria de navegação

[23] Comentário enviado por dolivervl em 09/03/2010 - 20:05h

Muito bom mesmo, Parabéns !!!

[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?

Abraço

[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.

[]'s

[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...

Já dizia o poeta: Fodástico![1]

[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.

[28] Comentário enviado por removido em 09/11/2010 - 08:35h

Sabia que o IIS da o mesmo problema e que é ainda pior que no apache?

[29] Comentário enviado por qxada07 em 24/03/2011 - 09:13h

Um artigo muito bom... Parabéns.....

Sempre achei o Apache muuuuito ferrado porém estes 2 integrados não tem para ninguém....

[30] Comentário enviado por SmasherBomb em 10/04/2011 - 13:43h

Parabéns...artigo muito bom !!

[31] Comentário enviado por fabgcruz em 15/04/2011 - 09:15h

Muito bacana o artigo .... maravilha !

[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.

[33] Comentário enviado por samuelspsd em 16/01/2012 - 17:24h

Eu teria algumas dúvidas em relação a este artigo, ainda está aberto para discussão? Obrigado.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts