conheça o apache 2.0 parte 2

3
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: 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). 1. 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). 2. 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 http://olinux.uol.com.br/artigos/412/print_preview.html 1 de 3 06-12-2009 12:38

Upload: felipe-santos

Post on 09-Jul-2015

561 views

Category:

Documents


12 download

TRANSCRIPT

Page 1: ConheçA O Apache 2.0   Parte 2

Conheça o Apache 2.0 - parte IIPor: 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ísticasdo Apache 2.0. Nas versões anteriores portabilidade era tratada internamente, feita dentro de padrões, porémpelos programadores. Com o 2.0 a portabilidade será orientada via APR, não será mais opção. O objetivo daAPR é 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 performancecompatível a chamadas Windows. Assim como em todas as outras plataforma. Isso proporciona um ganhobastante grande de performance. Tal interface e conceito foi feito pensado nas funções POSIX conhecidas pornós, programadores C. Só que é específico para as funcionalidades do Apache. Como percebido, facilita desobremaneira a portabilidade para outras plataformas.

Uma pergunta que pode surgir, é porque não usar POSIX puro para fazer isso, em vez do APR? Usando APRda mais flexibilidade para o desenvolvedor no sentido de POSIX ser uma padronização geral, seguida pormuitos, mas que é um nivelamento por baixo de funções básicas. Quase todas plataformas tem funções nãoPOSIX semelhantes que tem ganhos de performance ou funcionam mais adequadamente para determinadafunçã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çãode plataformas:

O Apache pode suportar uma grande quantidade de SOs mais limpo, manuseável e eficiente. Emparticular, a APR e a não necessidade de nivelar por baixo com o POSIX possibilita isso tudo(portabilidade).

1.

Adequação maior as necessidades particulares de cada site. Através da escolha da MPM você tem ascaracterí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 servirdiferentes domínios (virtual host) com níveis de acesso a máquina Usuários/Grupos diferenciados(escalabilidade/flexibilidade).

2.

Novos filtros

O que são filtros? Para cada requisição o Apache identifica o objeto de requisição, que pode ser umdocumento no disco, a saída de um CGI, a saída de um módulo como o de SSI (Server Side Include). Nãoexiste a habilidade nativa de se processar a saída de um script CGI interpretando tags SSI e devolvendo oresultado 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çõespara outras, encadeando-as.

No Apache 1.3 quando escrevemos um filtro, é bastante normal querermos modificar dados que chegam anós. Por exemplo, hipoteticamente estamos escrevendo um filtro para todas as páginas que são servidas pornós, botarmos um rodapé flutuante dizendo que aquela página pertence ao nosso provedor de serviços, quegratuitamente cede espaço aos usuários. Isso é bastante comum e acontece com vários provedores, como oconhecido Geocities. No Brasil, vindo a cabeça agora, temos o HPG, provedor de espaço que foi compradopelo IG. Em todas as páginas que ele fornece ele envia um popup dele, com suas propagandas, independente

http://olinux.uol.com.br/artigos/412/print_preview.html

1 de 3 06-12-2009 12:38

Page 2: ConheçA O Apache 2.0   Parte 2

da vontade do usuário do serviço. É uma maneira dele patrocinar suas operações e poder prestar esse tipo deserviço gratuito. Em casos como estes o caminho mais simples é escreve um módulo que intercepte todaconexã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 devidascorreções e enviar para o usuário, são exemplos válidos. Outra: gerar dados randomicamente, utilizando-sede cache para não despender recursos, feature usada em servidores de banners. Estes são os módulos maissimples 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) defluxos (stream), que são os módulos em cadeia (chaining content handlers, no guia de referência do Apachepara 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 scriptCGI (php por exemplo), depois inserirmos uma imagem randômica, adicionarmos a barra de navegaçãopadrão do site, dar include nas tags SSI (Server Side Include) e outras infinitas possibilidades. Nessassituações temos a saída dos prints do 1o módulo redirecionadas para a entrada do 2o, depois a saída do 2ovira entrada do 3o, e assim vai. Temos algumas questões como sincronização, cache, cabeçalhos, entreoutras 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, eprecisamos 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 eespero estar falando mais detalhadamente sobre isso, inclusive como portar os módulos da 1.3 para 2.0, semtraumas.

Piped Logs

Logs são uma parte importante das atividades em geral, não é diferente na Web. Todos precisam saber dadossobre visitas do site, erros que possam ter ocorrido durante as operações e outras informações que podem serretiradas dos mesmos. Os logs tendem a crescer indefinidamente com o crescimento das atividades do seusite e o passar do tempo.

Além disso, os logs são lentos de serem gerados, pois normalmente quando falamos em operações de redecostumamos substituir os endereços ips por nomes de máquinas (hostnames). Em geral os programasdesejam ser amigáveis com quem estão interagindo e haverá tradução de ips para nomes. Esse processoenvolve além de tudo serviço de terceiros, como um servidor DNS, lento. Em sites intensivos em tráfego issopode ser um problema.

Identificados estes dois problemas, tamanho de logs e lentidão na sua geração, podemos dizer que "PipedLogs" possibilitam contorná-los. No lugar de se escrever os logs para arquivos e o próprio Apache fazer todatradução e trabalho pesado, ele simplesmente passa para um processo a parte, e este se encarrega defazê-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 eoutros 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 seconcentra em servir o que ele tem q fazer mais eficientemente, sua funcionalidade core, enquanto o problemade logs é resolvido por outro processo, sem causar ônus para suas tarefas. Um adendo, em termos deconfiabilidade, faz-se checagens para garantir que o pipe esta persistente a maior parte do tempo. Apesar deser difícil haver uma quebra da conexão entre os processos (broken pipe), há uma preocupação e checagemem cima disso.

http://olinux.uol.com.br/artigos/412/print_preview.html

2 de 3 06-12-2009 12:38

Page 3: ConheçA O Apache 2.0   Parte 2

Copyright (C) 1999-2000 Linux Solutions

http://olinux.uol.com.br/artigos/412/print_preview.html

3 de 3 06-12-2009 12:38