1. http://olinux.uol.com.br/artigos/412/print_preview.html
Conheça o Apache 2.0 - parte II
Por: Elias Bareinboim ( 13/11/2001 )
APR (Apache Portable Run-Time)
Tem toda relação com o item anterior , em larga escala. É talvez a mais importante das novas características
do Apache 2.0. Nas versões anteriores portabilidade era tratada internamente, feita dentro de padrões, porém
pelos programadores. Com o 2.0 a portabilidade será orientada via APR, não será mais opção. O objetivo da
APR é prover uma interface em C para as funções específicas dependentes de plataforma.
Tal características tem vantagens como o código ficar mais bem arrumado e a manutenção ser facilitada.
Além disso, a essência, cada chamada usa código nativo sempre que possível. Se você esta no Windows,
você tem um programa que é nativamente escrito para Windows, com cara de Windows, com a performance
compatível a chamadas Windows. Assim como em todas as outras plataforma. Isso proporciona um ganho
bastante grande de performance. Tal interface e conceito foi feito pensado nas funções POSIX conhecidas por
nós, programadores C. Só que é específico para as funcionalidades do Apache. Como percebido, facilita de
sobremaneira a portabilidade para outras plataformas.
Uma pergunta que pode surgir, é porque não usar POSIX puro para fazer isso, em vez do APR? Usando APR
da mais flexibilidade para o desenvolvedor no sentido de POSIX ser uma padronização geral, seguida por
muitos, mas que é um nivelamento por baixo de funções básicas. Quase todas plataformas tem funções não
POSIX semelhantes que tem ganhos de performance ou funcionam mais adequadamente para determinada
função, e como temos um foco bem definido, performance, é importante esse tipo de maleabilidade.
Podemos citar algumas coisas implementadas via APR como funções básicas de I/O de arquivos, logs,
exclusão mútuas (semáforos), memória compartilhada, gerenciamento de processos filhos, IO assincrônico,
entre outros.
APR/MPM oferecem dois importantes benefícios com flexibilidade no tratamento de processos e diferenciação
de plataformas:
1. O Apache pode suportar uma grande quantidade de SOs mais limpo, manuseável e eficiente. Em
particular, a APR e a não necessidade de nivelar por baixo com o POSIX possibilita isso tudo
(portabilidade).
2. Adequação maior as necessidades particulares de cada site. Através da escolha da MPM você tem as
características mais adequadas para cada realidade, pode-se escolher entre faixas de escalabilidade,
confiabilidade, flexibilidade, robustez, entre outras características. Além de características de servir
diferentes domínios (virtual host) com níveis de acesso a máquina Usuários/Grupos diferenciados
(escalabilidade/flexibilidade).
Novos filtros
O que são filtros? Para cada requisição o Apache identifica o objeto de requisição, que pode ser um
documento no disco, a saída de um CGI, a saída de um módulo como o de SSI (Server Side Include). Não
existe a habilidade nativa de se processar a saída de um script CGI interpretando tags SSI e devolvendo o
resultado para o usuário. Podemos utilizando de artifícios (patches) para fazer isso com o servidor, mas é
bastante custoso e não muito prático. Através de filtros podemos redirecionar a saída de uma dessas ações
para outras, encadeando-as.
No Apache 1.3 quando escrevemos um filtro, é bastante normal querermos modificar dados que chegam a
nós. Por exemplo, hipoteticamente estamos escrevendo um filtro para todas as páginas que são servidas por
nós, botarmos um rodapé flutuante dizendo que aquela página pertence ao nosso provedor de serviços, que
gratuitamente cede espaço aos usuários. Isso é bastante comum e acontece com vários provedores, como o
conhecido Geocities. No Brasil, vindo a cabeça agora, temos o HPG, provedor de espaço que foi comprado
pelo IG. Em todas as páginas que ele fornece ele envia um popup dele, com suas propagandas, independente
1 de 3 06-12-2009 12:38

2. http://olinux.uol.com.br/artigos/412/print_preview.html
da vontade do usuário do serviço. É uma maneira dele patrocinar suas operações e poder prestar esse tipo de
serviço gratuito. Em casos como estes o caminho mais simples é escreve um módulo que intercepte toda
conexão e antes de enviar qualquer dado, insira o seu dado no fluxo que vai para o usuário.
Novos filtros (continuação)
Outros exemplos como passar um corretor ortográfico antes de enviar qualquer página, fazer as devidas
correções e enviar para o usuário, são exemplos válidos. Outra: gerar dados randomicamente, utilizando-se
de cache para não despender recursos, feature usada em servidores de banners. Estes são os módulos mais
simples que podem existir e não são complicados de serem desenvolvidos na versão 1.3.
Temos outros módulos um pouco mais complexos, quando temos situações de encadeamento (pipeline) de
fluxos (stream), que são os módulos em cadeia (chaining content handlers, no guia de referência do Apache
para mais informações) na versão 1.3.
Eles são usados quando queremos por exemplo corrigir a ortografia de um texto que foi saída de um script
CGI (php por exemplo), depois inserirmos uma imagem randômica, adicionarmos a barra de navegação
padrão do site, dar include nas tags SSI (Server Side Include) e outras infinitas possibilidades. Nessas
situações temos a saída dos prints do 1o módulo redirecionadas para a entrada do 2o, depois a saída do 2o
vira entrada do 3o, e assim vai. Temos algumas questões como sincronização, cache, cabeçalhos, entre
outras coisas, que não são das mais simples de se harmonizar. Muitas das partes de interação entre módulos
é feito pelo desenvolvedor. Não é das melhores coisas em produtividade, falando por experiência própria, e
precisamos de lidar com algumas situações baixo nível do servidor para poder ter um resultado adequado .
O Apache 2.0 tem nativamente o conceito de filtro embutido, a saída de uma ação sendo a entrada de outra,
genericamente, sem ter que se preocupar com nada. É muitíssimo útil para desenvolvedores de módulos e
espero estar falando mais detalhadamente sobre isso, inclusive como portar os módulos da 1.3 para 2.0, sem
traumas.
Piped Logs
Logs são uma parte importante das atividades em geral, não é diferente na Web. Todos precisam saber dados
sobre visitas do site, erros que possam ter ocorrido durante as operações e outras informações que podem ser
retiradas dos mesmos. Os logs tendem a crescer indefinidamente com o crescimento das atividades do seu
site e o passar do tempo.
Além disso, os logs são lentos de serem gerados, pois normalmente quando falamos em operações de rede
costumamos substituir os endereços ips por nomes de máquinas (hostnames). Em geral os programas
desejam ser amigáveis com quem estão interagindo e haverá tradução de ips para nomes. Esse processo
envolve além de tudo serviço de terceiros, como um servidor DNS, lento. Em sites intensivos em tráfego isso
pode ser um problema.
Identificados estes dois problemas, tamanho de logs e lentidão na sua geração, podemos dizer que "Piped
Logs" possibilitam contorná-los. No lugar de se escrever os logs para arquivos e o próprio Apache fazer toda
tradução e trabalho pesado, ele simplesmente passa para um processo a parte, e este se encarrega de
fazê-lo a sua moda.
Isso resolve os problemas citados acima da forma que você passa para o próximo, ou para você mesmo,
numa outra instância a resolução de problemas dos logs. Existem programas como logrotate, logresolve e
outros utilitário que podem fazer todo trabalho de rotação de logs por datas, tamanho, translação de nomes,
e toda parte de gerenciamento de logs. Isso permite uma maior flexibilidade no servidor de forma que ele se
concentra em servir o que ele tem q fazer mais eficientemente, sua funcionalidade core, enquanto o problema
de logs é resolvido por outro processo, sem causar ônus para suas tarefas. Um adendo, em termos de
confiabilidade, faz-se checagens para garantir que o pipe esta persistente a maior parte do tempo. Apesar de
ser difícil haver uma quebra da conexão entre os processos (broken pipe), há uma preocupação e checagem
em cima disso.
2 de 3 06-12-2009 12:38

3. http://olinux.uol.com.br/artigos/412/print_preview.html
Copyright (C) 1999-2000 Linux Solutions
3 de 3 06-12-2009 12:38