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.