[SP-pm] The Definitive Guide to Catalyst

[Thiago Glauco Sanchez]

Em 28/08/2010 21:00, Nilson Santos Figueiredo Jr. escreveu:
> 2010/8/28 Thiago Glauco Sanchez<thiagoglauco em ticursos.net>:
>    
>> Fui claro? Espero conseguir mais adeptos ao mod_perl depois disto...
>>      
> O mod_perl era o padrão até alguns anos atrás. Minha primeira
> aplicação em Catalyst, em 2007, foi deployed usando mod_perl. Com o
> tempo, a partir da *experiência prática*, a comunidade trocou o padrão
> para FastCGI por causa de diversos problemas *reais*, em produção,
> enfrentados com mod_perl. Um que já me afetou pessoalmente é o
> problema de quando o interpretador Perl dá crash por algum motivo,
> leva junto o processo do Apache. Isso pode ser algo raro, mas se torna
> comum quando você começa a combinar vários módulos XS, em especial o
> ImageMagick.
>
> Esses conselhos vem de experiência própria de diversos desenvolvedores
> que implantaram diversas aplicações reais e que tratam de um alto
> volume de tráfego. Não jogue isso fora e assuma que a sua experiência
> é mais valiosa. O padrão da comunidade foi evoluindo ao longo dos anos
> baseado na experiência coletiva, não foi uma pessoa que escreveu a sua
> preferência pessoal e isso virou norma.
>    
Em momento nenhum quero considerar minha experiência mais valiosa que a 
da comunidade. Ao contrário considero estas conversas muito produtivas e 
bom saber destes problemas. Considero antes as conversas uma troca de 
experiências. Pensei que a troca do mod_perl pelo fcgi se dava pela 
maior facilidade em configurar o FCGI em detrimento de outras 
características do mod_perl. Perceba que em 2007 nem pertencia a 
comunidade e levantar essa conversa ajuda a esclarecer os porques, mas 
como disse um colega, não lembro qual, uma vez: Um Hacker pergunta os 
porques e um macaco pergunta apenas como fazer.
Além do que estas conversas fazem perceber que algumas pessoas usam uma 
ou outra tecnologia apenas por que foi recomendado sem saber a fundo o 
que existe por traz da recomendação. Como, por exemplo, considerações 
sobre a criação de vários interpretadores do Perl não fazem mais sentido 
no mod_perl2. Minha explicação anterior surgiu por que um colega afirmou 
que o FCGI tem o desempenho melhor que o mod_perl, o que não é a pura 
verdade. Aproveitando a dica, vou evitar módulos XS em meus projetos.
Por outro lado o banco Inteligo substituiu sua solução de internet 
banking de uma solução Java para o mod_perl e o mojam.com roda 100% em 
Apache mod_perl e Mason... então ainda acho que o mod_perl não é algo 
para simplesmente se descartar.
Bugs fazem parte de qualquer desenvolvimento complexo e, infelizmente, 
shit happens... Acredito que seja melhor no longo prazo investir na 
evolução do mod_perl a abandona-lo e usar o FCGI. Soluções como o 
mod_php e os mod_<qqcoisa> estão se multiplicando por que, embora o FCGI 
atenda diversas linguagens é mais vantajoso a linguagem ter um módulo 
próprio que atenda suas características intrínsecas a uma solução geral, 
para diversas linguagens.
> -Nilson
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
>    


-- 
What is the sound of Perl? Is it not the sound of a wall that people have
stopped banging their heads against?
—Larry Wall

Thiago Glauco Sanchez
Intrutor Perl e Redes
www.ticursos.net