[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