Discussão

Tutoriais/Apache/Apache-performance

De Under-Linux.Org Wiki

Configurando Apache para Performance Maxima

Introdução

Apache é a implementação open source de um servidor HTTP. Ele é o webserver mais popular na Internet. Uma pesquisa realizada em 2005 pela NetCraft mostra que cerca de 70% dos sites na Internet rodam sobre o Apache.

Opções de Configuração em tempo de Compilação

Carrege apenas os módulos necessários

O servidor Apache é um programa modular onde o administrador pode escolher entre as funcinalidade que deseja incluir no servidor selecionando um pacote de módukis. Os módulos podem ser compilados estaticamente no binário httpd ou dinamicamente como DSOs(Dynamic Shared Objects). Módulos DSO podem ser compilados quando o servidor for compilado ou poem ser compilados utilizando o apxs para adicioná-los mais tarde. O modulo mod_so deve ser compilado estaticamente no Apache para que o suporte a DSO seja ativo.

Execute o apache apenas com os módulos necessários. Isto reduz o consumo de memória aumenta a performance do servidor. Compilar os módulos estaticamente irá reduzir o consumo de RAM que é utilizado para suportar módulos compilados dinamicamente, mas será necessário recompilar o apache toda vez que um módulo for adicionado ou removido. È aqui que o DSO se torna útil. Uma vez que o modulo mod_so seja compilado estaticamente, qualquer outro módulo pode ser inserido ou removido utilizando o comando LoadModule no arquivo httpd.conf - , mas você terá que compilar os módulos utilizando apxs se ele não foi compilado quando o servidor foi feito.

Escolha o MPM apropriado

O apache vem com uma selação de Módulos Multi-Processadores (MPMs) que são responsáveis por abrir as portas de rede na máquina, aceitando requisições, e despachando processos para cuidar das requisições. Apenas um MPM pode ser carregado por vez.

Escolher o MPM depende de vários fatores, por exemplo se o SO suporta threads, quanta memória está disponível, escalabilidade versus estabilidade, modulos externos,etc .. Sistemas Linux podem escolher entr utilizar um MPM com suporte (worker) a threads ou um prefork sem threads:

O MPM Worker utiliza múltiplos processos. Ele é multi-threaded com cada processo e cada thread cuidando de uma única conexão. Esté é mais rápido e mais escalável e a memória consumida e relativamente baixa. Funciona bem com múltiplos processadores. Porém, o worker é menos tolerante a módulos defeituosos, e threads defeituosas podem afetar todas as outras threads de um processo.

O MPM Prefork utiliza múltiplos processos filhos, cada filho cuidad de apenas uma conexão por vez. Prefork é muito bem gerenciada por processadores simples ou múlitplos, a velocidade é comparável ao worker e é mais tolerante a falhas em modulos e processos que terminam inesperadamente. Mas o consumo de memória é alto, mais tráfego leva a mais consumo de memória.

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

DNS lookup

A diretiva HostnameLookips habilita a consulta de DNS, então os hostnames podem ser logados ao invés de endereços IP. Isto adiciona latência em cada requisição desde que a consulta do DNS tem que ser completada antes que a requisição seja terminada. Esta opção é desabilitada por padrão no Apache 1.3 e superiores. Deixe isto inativo e utilize programas pós-processamento como o logresolve para determinar os IPs dos logs. Logresolve vem com Apache.

Quando utilizar as diretivas Allow from ou Deny from, utilize endereços IP ao invés de nomes de domínios. Caso contrário uma consulta dupla ao DNS será executada para ter certeza de que o domínio ou host não está sendo spoofado.

AllowOverride

Se o AllowOverride está setado para 'None', então o Apache irá tentar abrir o arquivo .htaccess (especificada pela diretiva AccessFileName) em cada diretório que for acessado. Por exemplo:

DocumentRoot /var/www/html
<Directory />
AllowOverride all
</Directory>

Se uma requisição for feita para acessar /index.html, o Apache irá tentar abrir /.htaccess, /var/.htaccess, /var/www/.htaccess, and /var/www/html/.htaccess. Estas tentativas aumentam a latência. Se o arquivo .htaccess for necessário para um diretório, habilite apenas para este diretório.

FollowSymLinks e SymLinksIfOwnerMatch

Se a opção FollowSymLinks estiver setada, então o servidor permitirá que links simbólicos possam ser seguidos neste diretório. Se a opção SymLinksIfOwnerMatch estiver setada, então o servidor permitirá acessar o link apenas se o destino dele bater com o dono do link.

Se a opção SymLinksIfOwnerMatch estiver setada, então o Apache terá que realizar consultas adicionais ao sistema para verificar se os donos coincidem. Chamadas adicionais também são necessárias quando a opção FollowSymLinks NÃO está setada. Por exemplo:

DocumentRoot /vaw/www/html 
<Directory /> 
Options SymLinksIfOwnerMatch 
</Directory>

Para uma requisição feita para /index.html, o Apache irá executar lstat() em /var, /var/www, /var/www/html, and /var/www/html/index.html. Estas requisições adicionais também irão aumentar a lantência. Os resultados do lstat não são cacheados, então as consultas irão ocorrer em cada requisição.

Para uma máxima performance, sete FollowSymLinks em cada lugar e nunca sete SymLinksIfOwnerMatch. Ou então, se SymLinksIfOwnerMatch for necessário para um diretório, sete ele para apenas este diretório.

Content Negotiation

Evite utilizar content negotiation para respostas mais rápidas. Se content negotiation é necessário para o site, utilize arquivos type-map ao invés da diretiva Options MultiViews. Com MultiViews, Apache precisa scanear o diretório em busca de arquivos, o que adiciona latência.

MaxClients

O MaxClients seta o número máximo de clientes simultâneos que pode ser suportada por cada servidor. Nenhum processo além do que está definido será aberto. Ele não deve conter um número muito baixo já que as requisições serão colacadas em fila, o que eventualmente irá dar time-out e os recursos do servidor continuarão não utilizados. Setar este valor muito alto irá causar o início de swap e o tempo de resposta irá cair drasticamente. O valor apropriado para MaxClientes pode ser calculado por: MaxClientes = Total RAM / Tamanho Máximo de Processos . O tamanho dos processos para arquivos estáticos é de mais ou menos 2-3MB. Para dinâmicos como PHP, deve ser por volta de 15MB. A coluna RSS de:

# ps -ylC httpd --sort:rss

Mostra a memória física non-swapped utilizada pelos processos do Apache em kilo Bytes.

Se existem mais usuários concorrentes do que MaxClients, as requisições serão colocadas em fila até o número baseado na diretiva ListenBacklog. Aumente o ServerLimit para setar o MaxClients acima de 256.

MinSpareServers, MaxSpareServers, e StartServers

MaxSpareServers e MinSpareServers determina quantos processos filhos devem ser mantidos rodando. Se MinSpareServers for muito baixo e muitas requisições forem iniciadas, então o Apache terá que abrir processos adicionais para atender as requisições. Criar processos filhos é relativamente caro. Se o servidor estiver ocupado criando processos, ele não estará disponível para servir as requisições imediatamente. MaxSpareServers não deve ser muito alto, ele pode causar problemas de recursos desde que cada processo consome os recursos da máquina.

Sete MinSpareServers e MaxSpareServers para um valor com que o Apache não precise frequentemente abrir mais de 4 processos por segundo. (O Apache pode abrir o máximo de 32 processos por segundo). Quando mais de 4 processos por segundo forem abertos, uma mensagem será logada no ErrorLog.

A diretiva StartServers define o número de processos criados na inicialização do Apache. O Apache irá continuar abrir os processos até que alcance o número de MinSpareServers. Não afeta muito a performance já que o servidor não é reiniciado frequentemente. Se existem muitas requisições e o Apache é reiniciado frequentemente, sete este valor para um número alto.

MaxRequestsPerChild

A diretiva MaxRequestsPerChild definie o número de requisições que um processo do servidor irá gerenciar. Depois as requisições MaxRequestsPerChild irão morrer. É definido para 0 por padrão, o que significa que o processo não irá expirar nunca. É apropriado setar este valor para alguns milhares. Isto pode ajudar a previnir vazamento de memória desde que o processo morre depois de servir um número de requisições. Não sete este valor muito baixo, já que criar novos processos causa overhead.

KeepAlive and KeepAliveTimeout

A diretiva KeepAilve permite que múltiplas requisições possam ser enviadas pela mesma conexão TCP. Isto é útil para páginas com muitas imagens. Se o KeepAlive estiver Off, então para cada imagem, uma nova conexão TCP precisa ser aberta.

KeepAliveTimeout determinada quanto tempo deve esperar até a próxima requisição. Sete para um valor baixo, por volta de 2 a 5 segundos. Se for setado para um valor muito alto, os processos ficam amarrados esperando pelo cliente quando eles poderiam ser utilizados para servir novos clientes.

Compressão HTTP & Caching

O servidor utiliza os métodos gzip ou deflate para as respostas payload antes que ele seja enviado para os clientes. Então o cliente descompacta o payload. Não existe necessidade de instalar softwares adicionais no lado do cliente desde que a maioria dos navegadores suporta isto. Utilizar compressão irá economizar banda e irá aumentar o tempo de resposta, estudos mostram que em média o ganho da compressão é de 75%. A compressão pode ser habilitada utilizando módulo mod_deflate. O Payload é compactado apenas se o navegador requisitar a compactação, ou então o conteúdo descompactado será enviado. Um navegador capaz de utilizar o conteúdo compactado envia o seguinte cabeçalho na requisição: "Accept-Encoding: gzip,deflate". Então o servidor irá enviar o payload compactado e o cabeçalho da reposta é "Content-Encoding: gzip"

O exemplo a seguir utiliza o telnet para verificar os cabeçalhos de requisição e de resposta:

bash-3.00$ telnet www.webperformance.org 80
Trying 24.60.234.27...
Connected to www.webperformance.org (24.60.234.27).
Escape character is '^]'.
HEAD / HTTP/1.1
Host: www.webperformance.org
Accept-Encoding: gzip,deflate

HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 02:29:22 GMT
Server: Apache/2.0
X-Powered-By: PHP/5.1.1
Cache-Control: max-age=0
Expires: Sat, 31 Dec 2005 02:29:22 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Content-Type: text/html; charset=ISO-8859-1

O module mod_cache pode ser utilizado no lado do servidor, está em produção estável na versão 2.2 do Apache.

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

Processos do apache para conteúdo dinâmico consome cerca de 3-20MB de RAM. E cresce para acomodar o conteúdo e nunca diminui até que o processo termine. Digamos que um processo cresca até os 20MB para servir um conteúdo dinâmico. Depois de completar a requisição, ele está libre para servir outra requisição. Se vier uma requisição para uma imagem, então esses 20MB de processos está servindo um conteúdo estático que poderia ser executado por um processo de 1MB. A memória é utilizada ineficientemente.

Utilize uma pequena compilação do Apache (com o mínimo de módulos compilados estaticamente) como sendo o servidor front-end para servir conteúdos estáticos. As requisições para conteúdos dinâmicos serão encaminhadas para um apache robusto (compilado com todos os módulos necessários). Utilizar um servidor front-end leve tem a vantagem de que os conteúdos estáticos são enviados rapidamente sem o consumo alto de memória e apenas o conteúdo dinâmico é passado para o servidor robusto.

Encaminhamento de requisições pode ser implementado utilizando os módulos mod_proxy e mod_rewrite. Suponha que exista um servidor apache leve rodando na porta 80 e o robusto na porta 8088. Então a configuração a seguir pode ser utilizada no apache leve para encaminhar todas as requisições de conteúdo dinâmico para o servidor robusto.

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

Todas as requisições, exceto as imagens serão encaminhadas para o apache robusto. As respostas são recebidas pelo servidor front-end que as encaminha para o cliente. Todas as respostas aparentam vir de um único servidor.

Conclusão

Configurar o Apache para obter o máximo de performance pode ser traiçoeiro, não existem regras rápidas. Entenda as necessidades do servidor web e experimente com várias opções. Utiliza ferramentas como ab e httperf para medir a performance do servidor. Servidores leves como tux, thttpd também podem ser utilizados como servidores front-end. Se um servidor de banco de dados é utilizado, tenha certeza de que ele está otimizado para que ele não crie nenhum gargalo. No caso do MySQL, mtop pode ser utilizado para monitorar querys lentas. Performance de scripts PHP pode ser melhorada utilizando produtos de cache como o Turck MMCache. Ele elimina o overhead da compilação realizando cache dos scripts em seu estado compilado.

Bibliografia

Fonte

http://www.howtoforge.net/configuring_apache_for_maximum_performance

Autor

Escrito por: Vishnu Ram is an MTech. in Communication Systems from IIT Madras. He joined Bobcares in 2003 and has been working for Poornam since then.

Obtida de "http://under-linux.org/wiki/Tutoriais/Apache/Apache-performance"