CGId: uma nova abordagem
O módulo de CGI fornece a possibilidade ao servidor
de rodar programas externos e produzir resultados
específicos para cada requisição. CGIs
são usadas pela maioria dos sites para produzir
conteúdo dinâmico, diferenciado por usuário e
contexto.
O Apache sempre teve suporte a CGI pelo módulo
mod_cgi. Quando um CGI é requisitado, o processo filho
chamado para atender a requisição cria um novo
processo para rodar o CGI. Após a execução do
programa a saída com os dados são redirecionadas
para o processo inicial, que repassa os dados ao cliente
original da requisição. Assim funciona na
versão 1.3, que tem problemas sérios de performance
e por isso existem módulos como o modperl, por exemplo,
que otimizam em muita operações com CGIs em Perl.
Sobre este assunto especificamente, citado no parágrafo
de respostas a requisições, mod_cgi, arquitetura
web, mod_perl, já tratei em artigos passados aqui na
Developers.
Para resolver esses problemas, na versão 2.0 temos
algumas possibilidades. Existem dois módulos, o mod_cgi,
que deve ser usada em plataformas não-Unix e com MPM de
prefork (compatibilidade) e o segundo módulo, o
mod_cgid, que pode ser usado em qualquer MPM Unix com
threads, a grande novidade.
O mod_cgid evita problemas de performance criando um
daemon específico para atender requisições de
CGI. Antes do start de qualquer filho do processo pai Apache,
no processo de inicialização, o servidor cria um
novo processo que será o servidor de CGI. Esse processo
cria um socket para comunicação com os filhos do
Apache pai. O servidor de CGI criará um processo para
rodar os CGIs, que comunicam-se diretamente com o processo
filho do Apache geral que recebeu a requisição. A
saída do processo CGI filho será enviado ao
processo Apache filho, que irá redirecioná-la para
o cliente. Existe um ganho considerável de performance
nessa conjuntura.
Obviamente, problemas surgem ao se criar um novo
?servidor?, mas que são contornados e valem o
custo/benefício pelo quesito performance, de forma
geral. Mecanismos semelhantes a recuperação de
perda de piped logs são usadas para o mesmo problema com
pipe entre os processos mod_cgid.
Conclusões
Estamos na versão 2.0.16 beta, que saiu em 9 de abril
deste ano. Ainda falta bastante trabalho mas a próxima
beta não tarda. As modificações como vistas
são muitas e indicam para dois aspectos fundamentais
já desenhados ao longo do texto: portabilidade e
escalabilidade.
Essas duas palavras genéricas que se relacionam
diretamente não são por acaso. É uma
imposição do mundo real, que não para de
crescer e multiplicar suas plataformas. Como vimos
vários aspectos da arquitetura do Apache, todo esse
esquema nos mostra que ele está mais enxuto, muito bem
modularizado, plugável, enfim, muito flexível.
Vimos que ele pretende fazer serviços de
infra-estrutura bem definidos e com excelência, com
foco, ser adaptável a situações diferenciadas
(conseguindo atender outros tipos de serviços), e mesmo
redirecionando tarefas que eram de sua responsabilidade em
versões anteriores para outros, como execução
de CGI, controle de Logs, etc.
Sua arquitetura é construída modularmente, onde
pode-se encaixar conforme suas próprias necessidades as
peças necessárias ao funcionamento ótimo para
cada um. É um quebra cabeça perfeito que se adapta
bem em qualquer serviço de infra-estrutura de redes, com
características intrínsecas de portabilidade e
escalabilidade. Não posso esquecer: a um custo zero.
Mediante todas essas constatações, a
tendência é que o Apache 2.0 mantenha-se líder
em seu segmento e tendendo a se expandir em outros nichos de
serviços e plataformas.
Referências:
