Configurando o Apache para Máxima Performance

Apache é uma implementação de servidor HTTP de código aberto. É o servidor web mais popular na Internet. A Pesquisa de Servidores Web de dezembro de 2005 conduzida pela Netcraft [

] mostra que cerca de 70% dos sites na Internet estão usando Apache.

1. Performance do servidor Apache

A performance do servidor Apache pode ser melhorada adicionando recursos de hardware adicionais, como RAM, CPU mais rápida, etc. Mas, na maioria das vezes, o mesmo resultado pode ser alcançado por meio de uma configuração personalizada do servidor. Este artigo analisa como obter a máxima performance do Apache com os recursos de hardware existentes, especificamente em sistemas Linux. Claro, assume-se que há recursos de hardware suficientes, especialmente RAM suficiente para que o servidor não esteja trocando frequentemente. As duas primeiras seções analisam várias opções de configuração em Tempo de Compilação e Tempo de Execução. A seção de Tempo de Execução assume que o Apache é compilado com MPM prefork. A compressão HTTP e o cache são discutidos a seguir. Finalmente, o uso de servidores separados para servir conteúdos estáticos e dinâmicos é discutido. Conhecimento básico de compilação e configuração do Apache e Linux é presumido.

2 Opções de Configuração em Tempo de Compilação

2.1 Carregar apenas os módulos necessários:

O Servidor HTTP Apache é um programa modular onde o administrador pode escolher a funcionalidade a incluir no servidor selecionando um conjunto de módulos [

]. Os módulos podem ser compilados estaticamente no binário httpd ou podem ser compilados como Objetos Compartilhados Dinâmicos (DSOs). Módulos DSO podem ser compilados quando o servidor é construído ou podem usar a utilidade apxs para compilar e adicionar em uma data posterior. O módulo mod_so deve ser compilado estaticamente no núcleo do Apache para habilitar o suporte a DSO.

Execute o apache apenas com os módulos necessários. Isso reduz a pegada de memória e, portanto, a performance do servidor. Compilar módulos estaticamente economiza RAM que é usada para suportar módulos carregados dinamicamente, mas é necessário recompilar o Apache sempre que um módulo for adicionado ou removido. É aqui que o mecanismo DSO se torna útil. Uma vez que o módulo mod_so é compilado estaticamente, qualquer outro módulo pode ser adicionado ou removido usando o comando LoadModule no arquivo httpd.conf - claro, você terá que compilar os módulos usando apxs se não tiver sido compilado quando o servidor foi construído.

2.2 Escolher MPM apropriado:

O servidor Apache é fornecido com uma seleção de Módulos de Multi-Processamento (MPMs) que são responsáveis por vincular a portas de rede na máquina, aceitar solicitações e despachar filhos para lidar com as solicitações [

]. Apenas um MPM pode ser carregado no servidor a qualquer momento.

Escolher um MPM depende de vários fatores, como se o SO suporta threads, quanta memória está disponível, escalabilidade versus estabilidade, se módulos de terceiros não seguros para threads estão sendo usados, etc. Sistemas Linux podem optar por usar um MPM com threads como worker ou um MPM sem threads como prefork:

O MPM Worker usa múltiplos processos filhos. É multi-threaded dentro de cada filho e cada thread lida com uma única conexão. O Worker é rápido e altamente escalável e a pegada de memória é comparativamente baixa. É bem adequado para múltiplos processadores. Por outro lado, o worker é menos tolerante a módulos defeituosos e threads defeituosas podem afetar todas as threads em um processo filho.

O MPM Prefork usa múltiplos processos filhos, cada filho lida com uma conexão por vez. O Prefork é bem adequado para sistemas de CPU única ou dupla, a velocidade é comparável à do worker e é altamente tolerante a módulos defeituosos e filhos que falham. Mas o uso de memória é alto, mais tráfego leva a mais uso de memória.

3 Opções de Configuração em Tempo de Execução

3.1 Pesquisa DNS:

A diretiva HostnameLookups habilita a pesquisa DNS para que nomes de host possam ser registrados em vez do endereço IP. Isso adiciona latência a cada solicitação, uma vez que a pesquisa DNS deve ser concluída antes que a solicitação seja finalizada. HostnameLookups está desativado por padrão no Apache 1.3 e acima. Deixe-o desativado e use um programa de pós-processamento como logresolve para resolver endereços IP nos arquivos de log de acesso do Apache. O logresolve é fornecido com o Apache.

Ao usar as diretivas Allow from ou Deny from, use o endereço IP em vez de um nome de domínio ou um nome de host. Caso contrário, uma pesquisa DNS dupla é realizada para garantir que o nome de domínio ou o nome de host não esteja sendo falsificado.

3.2 AllowOverride:

Se AllowOverride não estiver definido como ‘None’, então o Apache tentará abrir o arquivo .htaccess (conforme especificado pela diretiva AccessFileName) em cada diretório que visita. Por exemplo:

DocumentRoot /var/www/html  
   
 AllowOverride all

Se uma solicitação for feita para o URI /index.html, então o Apache tentará abrir /.htaccess, /var/.htaccess, /var/www/.htaccess, e /var/www/html/.htaccess. Essas buscas adicionais no sistema de arquivos aumentam a latência. Se .htaccess for necessário para um diretório específico, então habilite-o apenas para aquele diretório.

3.3 FollowSymLinks e SymLinksIfOwnerMatch:

Se a opção FollowSymLinks estiver definida, então o servidor seguirá links simbólicos neste diretório. Se SymLinksIfOwnerMatch estiver definido, então o servidor seguirá links simbólicos apenas se o arquivo ou diretório de destino for de propriedade do mesmo usuário que o link.

Se SymLinksIfOwnerMatch estiver definido, então o Apache terá que emitir chamadas de sistema adicionais para verificar se a propriedade do link e do arquivo de destino correspondem. Chamadas de sistema adicionais também são necessárias quando FollowSymLinks NÃO está definido. Por exemplo:

 DocumentRoot /vaw/www/html   
    
 Options SymLinksIfOwnerMatch

Para uma solicitação feita para o URI /index.html, o Apache realizará lstat() em /var, /var/www, /var/www/html, e /var/www/html/index.html. Essas chamadas de sistema adicionais aumentarão a latência. Os resultados do lstat não são armazenados em cache, então ocorrerão em cada solicitação.

Para máxima performance, defina FollowSymLinks em todos os lugares e nunca defina SymLinksIfOwnerMatch. Ou, se SymLinksIfOwnerMatch for necessário para um diretório, então defina-o apenas para aquele diretório.

3.4 Negociação de Conteúdo:

Evite a negociação de conteúdo para uma resposta rápida. Se a negociação de conteúdo for necessária para o site, use arquivos type-map em vez da diretiva Options MultiViews. Com MultiViews, o Apache tem que escanear o diretório em busca de arquivos, o que aumenta a latência.

3.5 MaxClients:

O MaxClients define o limite de solicitações simultâneas máximas que podem ser suportadas pelo servidor. Não mais do que esse número de processos filhos é gerado. Não deve ser definido muito baixo a ponto de novas conexões serem colocadas em fila, o que eventualmente expira e os recursos do servidor ficam não utilizados. Definir isso muito alto fará com que o servidor comece a trocar e o tempo de resposta diminuirá drasticamente. O valor apropriado para MaxClients pode ser calculado como: MaxClients = RAM total dedicada ao servidor web / Tamanho máximo do processo filho —- [

] O tamanho do processo filho para servir arquivos estáticos é de cerca de 2-3M. Para conteúdo dinâmico, como PHP, pode ser em torno de 15M. A coluna RSS em

"ps -ylC httpd --sort:rss"

mostra o uso de memória física não trocada pelos processos do Apache em kilobytes.

Se houver mais usuários concorrentes do que MaxClients, as solicitações serão enfileiradas até um número baseado na diretiva ListenBacklog. Aumente ServerLimit para definir MaxClients acima de 256.

3.6 MinSpareServers, MaxSpareServers e StartServers:

MaxSpareServers e MinSpareServers determinam quantos processos filhos manter enquanto aguardam solicitações. Se o MinSpareServers for muito baixo e um monte de solicitações chegar, então o Apache terá que gerar processos filhos adicionais para atender às solicitações. Criar processos filhos é relativamente caro. Se o servidor estiver ocupado criando processos filhos, não poderá atender imediatamente às solicitações dos clientes. MaxSpareServers não deve ser definido muito alto, pois pode causar problemas de recursos, uma vez que os processos filhos consomem recursos.

Ajuste MinSpareServers e MaxSpareServers de forma que o Apache não precise gerar frequentemente mais de 4 processos filhos por segundo (o Apache pode gerar um máximo de 32 processos filhos por segundo). Quando mais de 4 filhos são gerados por segundo, uma mensagem será registrada no ErrorLog.

A diretiva StartServers define o número de processos de servidor filhos criados na inicialização. O Apache continuará criando processos filhos até que a configuração MinSpareServers seja atingida. Não tem muito efeito na performance se o servidor não for reiniciado frequentemente. Se houver muitas solicitações e o Apache for reiniciado frequentemente, defina isso para um valor relativamente alto.

3.7 MaxRequestsPerChild:

A diretiva MaxRequestsPerChild define o limite no número de solicitações que um processo filho individual do servidor lidará. Após MaxRequestsPerChild solicitações, o processo filho morrerá. Está definido como 0 por padrão, o que significa que o processo filho nunca expirará. É apropriado definir isso para um valor de alguns milhares. Isso pode ajudar a prevenir vazamentos de memória, uma vez que o processo morre após atender a um certo número de solicitações. Não defina isso muito baixo, pois criar novos processos tem uma sobrecarga.

3.8 KeepAlive e KeepAliveTimeout:

A diretiva KeepAlive permite que várias solicitações sejam enviadas pela mesma conexão TCP. Isso é particularmente útil ao servir páginas HTML com muitas imagens. Se KeepAlive estiver definido como Off, então para cada imagem, uma conexão TCP separada deve ser feita. A sobrecarga devido ao estabelecimento da conexão TCP pode ser eliminada ativando o KeepAlive.

KeepAliveTimeout determina quanto tempo esperar pela próxima solicitação. Defina isso para um valor baixo, talvez entre dois a cinco segundos. Se for definido muito alto, os processos filhos ficam ocupados esperando pelo cliente quando poderiam ser usados para atender novos clientes.

4 Compressão HTTP & Cache

A compressão HTTP é completamente especificada no HTTP/1.1. O servidor usa o método de codificação gzip ou deflate para a carga útil da resposta antes de enviá-la ao cliente. O cliente então descomprime a carga útil. Não há necessidade de instalar nenhum software adicional no lado do cliente, uma vez que todos os principais navegadores suportam isso. Usar compressão economizará largura de banda e melhorará o tempo de resposta, estudos descobriram um ganho médio de compressão de 75,2 % [

]. A compressão HTTP pode ser habilitada no Apache usando o módulo mod_deflate. A carga útil é comprimida apenas se o navegador solicitar compressão, caso contrário, o conteúdo não comprimido é servido. Um navegador ciente da compressão informa ao servidor que prefere conteúdo comprimido através do cabeçalho de solicitação HTTP - “Accept-Encoding: gzip,deflate”. Então o servidor responde com a carga útil comprimida e o cabeçalho de resposta definido como “

Content-Encoding:  
gzip

O seguinte exemplo usa telnet para visualizar os cabeçalhos de solicitação e resposta:

bash-3.00$ telnet www.webperformance.org 80  
 Tentando 24.60.234.27...  
 Conectado a www.webperformance.org (24.60.234.27).  
 O caractere de escape é '^]'.  
 HEAD / HTTP/1.1  
 Host: www.webperformance.org  
 Accept-Encoding: gzip,deflate  
   
 HTTP/1.1 200 OK  
 Data: Sáb, 31 Dez 2005 02:29:22 GMT  
 Servidor: Apache/2.0  
 X-Powered-By: PHP/5.1.1  
 Cache-Control: max-age=0  
 Expires: Sáb, 31 Dez 2005 02:29:22 GMT  
 Vary: Accept-Encoding  
 Content-Encoding: gzip  
 Content-Length: 20  
 Content-Type: text/html; charset=ISO-8859-1

No cache, uma cópia dos dados é armazenada no cliente ou em um servidor proxy para que não precise ser recuperada frequentemente do servidor. Isso economizará largura de banda, diminuirá a carga no servidor e reduzirá a latência. O controle de cache é feito através de cabeçalhos HTTP. No Apache, isso pode ser realizado através dos módulos mod_expires e mod_headers. Também há cache do lado do servidor, no qual os conteúdos frequentemente acessados são armazenados na memória para que possam ser servidos rapidamente. O módulo mod_cache pode ser usado para cache do lado do servidor, ele é estável em produção na versão 2.2 do Apache.

5 Servidor separado para conteúdo estático e dinâmico

Os processos do Apache que servem conteúdo dinâmico consomem cerca de 3M a 20M de RAM. Ele cresce para acomodar o conteúdo que está servindo e nunca diminui até que o processo morra. Digamos que um processo do Apache cresça para 20M para servir um conteúdo dinâmico. Após completar a solicitação, ele está livre para atender qualquer outra solicitação. Se uma solicitação para uma imagem chegar, então esse processo de 20M está servindo um conteúdo estático que poderia muito bem ser servido por um processo de 1M. A memória é usada de forma ineficiente.

Use um Apache pequeno (com módulos mínimos compilados estaticamente) como servidor front-end para servir conteúdos estáticos. Solicitações para conteúdos dinâmicos são encaminhadas para o Apache pesado (compilado com todos os módulos necessários). Usar um servidor front-end leve tem a vantagem de que os conteúdos estáticos são servidos rapidamente sem muito uso de memória e apenas os conteúdos dinâmicos são passados para o servidor pesado.

O encaminhamento de solicitações pode ser realizado usando os módulos mod_proxy e rewrite_module. Suponha que haja um servidor Apache leve escutando na porta 80 e o Apache pesado escutando na porta 8088. Então, a seguinte configuração no Apache leve pode ser usada para encaminhar todas as solicitações, exceto solicitações para imagens, para o servidor pesado.

ProxyPassReverse / http://%{HTTP_HOST}:8088/  
 RewriteEngine on                                             ---- [9]  
 RewriteCond   %{REQUEST_URI} !.*\.(gif|png|jpg)$  
 RewriteRule ^/(.*) http://%{HTTP_HOST}:8088/$1 [P]

Todas as solicitações, exceto para imagens, são proxy para o servidor de backend. A resposta é recebida pelo servidor front-end e, em seguida, fornecida ao cliente. No que diz respeito ao cliente, todas as respostas parecem vir de um único servidor.

6 Conclusão

Configurar o Apache para máxima performance é complicado, não há regras rígidas e rápidas. Entenda os requisitos do servidor web e experimente várias opções disponíveis. Use ferramentas como ab e httperf para medir a performance do servidor web. Servidores leves como tux, thttpd também podem ser usados como servidor front-end. Se um servidor de banco de dados for usado, certifique-se de que ele esteja otimizado para que não crie nenhum gargalo. No caso do MySQL, mtop pode ser usado para monitorar consultas lentas. A performance de scripts PHP pode ser melhorada usando um produto de cache PHP como Turck MMCache. Ele elimina a sobrecarga devido à compilação armazenando os scripts PHP em estado compilado.

Bibliografia

1 http://news.netcraft.com/archives/web_server_survey.html

2 http://httpd.apache.org/docs/2.2/dso.html

3 http://httpd.apache.org/docs/2.2/mpm.html

4 http://modperlbook.org/html/ch11_01.html

5 http://www.speedupyoursite.com/18/18-2t.html

6 http://www.xs4all.nl/~thomas/apachecon/PerformanceTuning.html

7 http://www.onlamp.com/pub/a/onlamp/2004/02/05/lamp_tuning.html

8 http://httpd.apache.org/docs/2.2/misc/perf-tuning.html

9 Linux Server Hacks by Rob Flickenger

Biografia do Autor: Vishnu Ram é MTech. em Sistemas de Comunicação pelo IIT Madras. Ele se juntou à Bobcares em 2003 e tem trabalhado para a Poornam desde então.