[Cascavel-pm] Por falar em modperl...

[Ednardo Lobo]

On Fri, Mar 28, 2003 at 01:57:50PM -0300, Luis Campos de Carvalho wrote:
> ----- Original Message -----
> From: "Luciano Greiner" <lup em terra.com.br>
> Sent: Friday, March 28, 2003 1:00 PM
> 
> 
> > Oi pessoal...
> >
> >   estou ouvindo ModPerl na lista, então lembrei de uma dúvida que eu
> > tenho. Estou fazendo  um webserverzinho de brincadeira  aqui e quero
> > adicionar suporte a  Perl nele. Porém eu acho a  solução de disparar
> > um interpretador Perl  para cada CGI invocado no  servidor a maneira
> > mais burra de fazer isso, e tenho certeza que o ModPerl não faz isso
> > assim. Vocês sabem mais ou menos como funciona?
>
>   O Mod_Perl  é um Handler do  Apache que roda um  interpretador Perl.
> Funciona  mais ou  menos como  todas  as outras  extensões do  Apache:
> carrega na inicialização, tem várias  instâncias e recebe / processa /
> devolve requisições de um dos 13  tipos (é esse o número?) de Handlers
> que compõem a cadeia de processamento de requisições do Apache. O fato
> de  uma  instância  ModPerl  ficar  direto  online  pode  complicar  a
> vida  de  quem  pensa  de  maneira "stateless":  você  se  esquece  de
> limpar variáveis, e  acaba com respostas estranhas  depois da primeira
> requisição.
>

    Nos últimos meses tenho programado  um grande sistema WEB, com perl,
em cima  de um  Apache com  mod_perl. O ganho  de desempenho  é bastante
satisfatório e  da ordem de  200% a 4000%.  Recomendo bastante o  uso do
mod-perl em detrimento ao mod_cgi. Porém,  nem todos os scripts perl que
rodam em mod-cgi  irão rodar em mod_perl. Regra geral,  se você usa 'use
strict' e seu script é interpretado sem reportar erros com '-w', ele irá
funcionar  em mod_perl.  É preciso,  entretanto, ter  muita atenção  com
variáveis globais e ser uma pouco mais cuidadoso durante a programação.

    Eu  tive um  estranho  probleminha  com o  mod_perl,  que ainda  não
consegui solucionar:


            Não sei  por que razão, quando  o trecho de código  abaixo é
        executado via `mod_perl', no Apache,  o resultado é diferente do
        esperado:

                my $linha = <STDIN>;

                print "$linha\n";

            Isso deveria  imprimir a  primeira linha apenas,  mas quando
        executado via mod_perl, todas as linhas são impressas. Alguém já
        se deparou com isso?
                    

    Além do  ganho de  desempenho, ainda  não consegui  explorar nenhuma
outra vantagem que  o mod_perl possa oferecer em relação  ao mod_cgi. Se
alguém  utiliza algum  recurso obscuro  do mod_perl,  gostaria muito  de
trocar idéias.


>   Acho que você pode aprender bastante no website do ModPerl:
> 
>   http://perl.apache.org/
>
> > Existe  alguma  maneira  de  explorar  concorrência  aqui?  Usar  um
> > interpretador  para vários  scripts usando  threads... ?  O que  vcs
> > indicam?
>
>   Você  pode se  aproveitar da  menor  carga de  trabalho gerada  pelo
> processamento de scripts dentro do ModPerl, que não precisa carregar o
> interpretador perl  em cada  nova execução.  Também vai  sentir alguma
> diferença com o uso de cache de scripts pré-compilados, desde que siga
> algumas  pequenas restrições  para construí-los.  Leia a  documentação
> para saber mais sobre isso.
>
>   Quando  a  usar  threads,  acho mais  complicado...  o  ModPerl  usa
> processos,  sobe  alguns  interpretadores para  servir  requisições  e
> processa  cada requisição  sequencialmente, exatamente  como o  Apache
> faz.
>
>   Ainda  assim, o  ganho de  performance é  considerável, vale  à pena
> conhecer.
>
>   Espero que isso o estimule.
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>   Luis Campos de Carvalho
>   Computer Science Student
>   OCP DBA Oracle & Unix Sys Admin
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-- 
    Ednardo Lobo - www.elobo.cjb.net

    Por favor, evitem enviar anexos no formato MS-Office, obrigado!
    Veja: http://www.fsf.org/philosophy/no-word-attachments.pt.html

--
Your lucky number is 3552664958674928.  Watch for it everywhere.