[SP-pm] The Definitive Guide to Catalyst
Thiago Glauco Sanchez
thiagoglauco at ticursos.net
Sat Aug 28 12:55:43 PDT 2010
Em 28/08/2010 09:51, Lindolfo "Lorn" Rodrigues escreveu:
> Fiquei curioso, que vantagem é essa que o mod_perl tem? pode falar um
> pouco sobre esse handlers?
> Eu acho que arquiteturas com nginx + Starman muito mais interessante e
> escaláveis.
>
> PS: Questão de rubish? :P
Muito bem Lorn... primeiro a questão do Rubish.... Como programador,
posso dizer que sou bottom-up. Ou seja,eu gosto de aprende como as
coisas funcionam por baixo dos frameworks antes mesmo de aprender os
frameworks. Então, você pode colocar uma aplicação feita no Catalyst,
por exemplo, para rodar tanto com CGI quanto com FASTCGI ou mod_perl.
Embora um desenvolvedor possa ficar ficar apenas com o Catalyst, como
administrador de redes e tecnologo em automação eu gosto de ver como as
coisas funcionam. Por isso, mesmo podendo fazer as coisas apenas com
Catalyst, eu gosto do mod_perl. Até por que as aplicações Catalyst vão
no final das contas, mas não necessariamente, vão rodar ou no FCGI ou no
mod_perl...
Não conheço a arquitetura nginx + Starman. Então peço uma explicação em
retorno.
Antes de começar quero deixar claro que não sou defensor xiita desta ou
aquela solução. E como o Eden já esclareceu existem vantagens
consideráveis no FastCGI. Pois ele tem uma performance muito boa, é
relativamente fácil encontrar provedores com suporte ao FastCGI e o
FastCGI é muiiiito mais fácil de configurar que o mod_perl2 e é
idependete da linguagem. Então, da mesma forma que posso fazer um CGI
com C ou Shell, posso fazer programas FCGI com Perl, C ou Shell. Já, o
mod_perl, assim como o mod_php é exclusivo e otimizado para o Perl.
Porém o mod_perl permite como primeira grande vantagem, utilizar scripts
CGI antigos sem modificação, porém não utilizando 100% da performance e
das facilidades do mod_perl. Para isto bastaria configurar o PerlModule
Apache::Registry no httpd.conf ou apache2.conf dependendo do seu
servidor. Existiam em 2002 mais de 500 módulos mod_perl no CPAN (Apache
2 Sever Bible - Hungry minds). O que é uma boa economia de código e uma
vantagem às outras linguagens por si só (não digo as outras formas de
programar com Perl pois existem muitos módulos CPAN para FCGI, CGI, etc...).
Apesar da otimização que o mod_perl oferece para o CGI eles não foram
feitos para o mod_perl, e um script para mod_perl teria a seguinte
aparência:
package MinhasWebLibs::MeuModulo;
sub handler {
#Alguma coisa útil aqui
}
sub module_method_1 { # Alguma coisa útil aqui }
sub module_method_2 { # Alguma coisa útil aqui }
sub module_method_3 { # Alguma coisa útil aqui}
...
sub module_method_N { # Alguma coisa útil aqui }
1;
e exigiria uma configuração adicional no servidor:
PerlModule MinhasWebLibs::MeuModulo
<Location /MinhaApp>
SetHandler perl-script
PerlHandler MinhasWebLibs::MeuModulo
</Location>
Isso permitiria acessar meu script com a URI
http://www.meusite.com.br/MinhaApp. Básicamente isto é um handler. Um
módulo Perl pré carregado na memória que responderá a uma solicitação
GET ou POST para a qual ele está configurado no próprio apache. Perceba
que no Apache2, adicionado a linha PerlModule MinhasWebLibs::MeuModulo
vai compilar o módulo no boot do serviço.
Mas otimizar o mod_perl2 por desempenho vai além disso. Como o Eden
mencionou o mod_perl pode consumir muita memória, o que pode ser
otimizado compatilhando certos módulos na memória.
Por exemplo, adicionando ao arquivo de configuração do apache2 os
módulos CPAN que são comuns a diversas aplicações, como abaixo:
PerlModule CGI
PerlModule DBI
Fará com que o mod_perl2 carregue estes módulos apenas uma vez,
independente de quantas aplicações os usem, economizando muita memória.
O Eden mencionou a memoria por fork:
>>>Outra
coisa é que a assinatura de memória da sua aplicação usando mod_perl é
bem maior, porque cada fork vai conter um interpretador de perl inteiro
Se não me engano tem como tweakar isso pra compartilhar
a memória da aplicação mas não vejo como fazer isso seria possível com o
interpretador<<<<
O Fork é uma abordagem do Apache1 e 1.3. O Apache2 é bem flexível, sendo
isto um problema mais da escolha de funcionamento do que do mod_perl2 se
entendi bem o que você explicou aqui... se não, fique a vontade para me
corrigir. O Apache2 permite uma abordagem PreFork (apache 1.3 compliant)
MPM que é tal qual você disse;
uma abordagem Thread MPM que permite, digamos, que eu inicie a minha
aplicação com 50 processos, cada processo com 20 threads, permitindo
1000 acessos simultâneos sem precisar carregar nada adicional na
memória, isso deve ser configurado conforme seu hardware e expectativa
de acessos ao seu site.
e Child MPM que você pode ler na documentação do Apache2.
>>>
Com fastcgi, por padrão, a memória do processo é
compartilhada então só tem uma instância do interpretador e da sua
aplicação e as variáveis usam copy-on-write, diminuindo
significativamente a assinatura de memória da aplicação e requer menos
processamento para iniciar processos adicionais
<<<
Veja um problema com a segurança. Se um usuário ou módulo com algum bug
um gerar um erro no processo, sua aplicação fica inacessível. Enquanto
que na abordagem Thread MPM eu teria que derrubar 50 processos.
Além disto esta abordagem foi modificada no mod_perl2:
>>>Apache2 Documentation:
Rather than create a |PerlInterperter| per-thread by default, mod_perl
creates a pool of interpreters. The pool mechanism helps cut down memory
usage a great deal. As already mentioned, the syntax tree is shared
between all cloned interpreters. If your server is serving more than
mod_perl requests, having a smaller number of PerlInterpreters than the
number of threads will clearly cut down on memory usage. Finally and
perhaps the biggest win is memory re-use: as calls are made into Perl
subroutines, memory allocations are made for variables when they are
used for the first time. Subsequent use of variables may allocate more
memory, e.g. if a scalar variable needs to hold a longer string than it
did before, or an array has new elements added. As an optimization, Perl
hangs onto these allocations, even though their values "go out of
scope". mod_perl 2.0 has a much better control over which
PerlInterpreters are used for incoming requests. The interpreters are
stored in two linked lists, one for available interpreters and another
for busy ones. When needed to handle a request, one interpreter is taken
from the head of the available list and put back into the head of the
same list when done. This means if for example you have 10 interpreters
configured to be cloned at startup time, but no more than 5 are ever
used concurrently, those 5 continue to reuse Perl's allocations, while
the other 5 remain much smaller, but ready to go if the need arises.
<<<<<
Fui claro? Espero conseguir mais adeptos ao mod_perl depois disto...
Realmente o mod_perl exige mais configurações que o FCGI e o FCGI
apresenta uma boa performance para a maioria das aplicações e não se
limita ao Perl nem ao Apache. Mas como o Apache2 é intrinsecamente
ligado com o Perl, não vejo por que não usa-lo com o Perl.
Principalmente pq ele se aproxima do meu modo de pensar e é o servidor
web mais usado no mundo. E como eu espero ter demonstrado acima, se bem
configurado tem um excelente desempenho para aplicações robustas e com
muitos acessos simultâneos.
Ah... outra vantagem do mod_perl2 é o acesso a API do apache, até então
acessível apenas para programadores C...
>
> 2010/8/27 <thiagoglauco em ticursos.net <mailto:thiagoglauco em ticursos.net>>
>
> Se o seu fastcgi esta melhor que o mod_perl, ou o seu projeto foi
> muito simples para se precisar usar o mod_perl, ou você não fez
> todas as configurações de mod_perl necessárias... Ou mesmo a
> programação em mod_perl, com handles é um pouco diferente da
> programação ordinária... :-)
>
> Mas eu tenho necessidade de ambos mesmo, por questão de rubish!!!
>
>
>
>
> --
> lorn at lornlab dot org
> Lindolfo "Lorn" Rodrigues
>
>
> _______________________________________________
> 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
More information about the SaoPaulo-pm
mailing list