ConheçA O Apache 2.0 Parte 2
- 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