Olá. Eu, usando Gentoo linux. parece que não consigo emergir/instalar o mod_perl com um apache2 encadeado, então gostaria de saber quais são os prós e os contras de usar o módulo de trabalho do apache2 com cgi-perl e usar o módulo prefork do apache2 com mod_perl
o que é mais rápido? o que consome menos recursos? em termos de segurança, há alguma diferença?
obrigado!
Responder1
No Linux, use o prefork apache com mod_perl. O Threaded MPM é uma grande vitória para usuários Win32, onde a criação de processos é cara. No Linux, fork() é uma chamada bem barata. No entanto, os desenvolvedores do Mod_perl2 fizeram um grande esforço para fazer o mod_perl2 funcionar com threads Apache2 +, mas o modelo de thread em perl consome um pouco de memória.
Desenvolvemos um grande aplicativo mod_perl e se tivéssemos que recriá-lo hoje provavelmente recomendaria um dos vários frameworks e usaria FastCGI ouPSGI. Usar FCGI ou um framework com recursos PSGI/FCGI nativos permite que você escolha front-ends (nginx, lighttpd, apache2). Você pode fazer chroot em seu aplicativo e diminuir seus privilégios (ele só precisa de um soquete para se comunicar com seu front-end). Se você fizer seu aplicativo usar mod_perl2, você estará praticamente casado com o Apache2.
Responder2
IMHO, prefork+mod_per seria muito mais rápido, mas perguntar na lista de discussão mod_perl lhe daria uma resposta mais exata
Responder3
Modperl é um adaptador perfeito para Catalyst, da mesma forma que Modpython e Modwsgi são para Django, e modphp é para Cakephp, enquanto Modruby está sendo debatido como melhor ou pior que cgi, fcgi e (Modrails/Modpassenger/Modlocomotive) são para Rails especialmente ao usar o modo threaded (mas existem Modrake e proxy Mongrel app-server como alternativas). Para evitar as desvantagens e obter apenas vantagens, use sempre o modo bifurcado. Estou usando me referindo apenas a mvcs de outras linguagens de programação inspiradas em Rails: ou seja, Catalyst, Django, Cakephp e Rails.
Na minha opinião, o modo mpm-itk multiforked é o melhor, seguido pelo modo mpm-event multithread, depois vem o modo mpm-prefork bifurcado único e, por último, vem o modo mpm-worker de thread único.
Descobri que para algumas linguagens de programação seus respectivos adaptadores apache2, como mod-php e mod-tcl, rodam especificamente apenas no modo prefork e nem mesmo no modo itk, enquanto o mod-ruby ainda está apenas no linux-apache2 e ainda para faça isso no windows-apache2.
Mas, felizmente, mode-perl, mod-python e mod-ruby são mais versáteis o suficiente e podem ser executados em todos os quatro modos - modo libapache-mpm-worker, modo libapache-mpm-prefork, libapache-mpm-event modo e modo libapache-mpm-itk. Esta é uma boa notícia para usuários de perl, python e ruby, mas é claro que mesmo no caso dos três adaptadores, o modo bifurcado é mais rápido, mais versátil e livre de conflitos do que o modo threaded. E uma coisa é certa: todos esses adaptadores foram projetados para funcionar mais rápido que o cgi e, possivelmente, tão rápido quanto o fcgi (fastcgi).
Eu uso o modo itk (multifork), mesmo que isso signifique que faltarão alguns softwares que exigem o modo prefork (bifurcação única).
Sempre preferi o modo itk no Ubuntu e nunca optei por instalar aplicativos que exijam o modo prefork como pré-requisito. Algumas distros como Sabayon, que é do tipo Gentoo, instalam o Apache2 no modo de trabalho por padrão. Mas isso sempre podemos mudar editando o arquivo de configuração do sistema apache e descomentando as linhas que contêmok(e comente as linhas paratrabalhador) seguido de recompilação e reinicialização do apache2. Então, tudo o que se aplica ao Sabayon também deve valer para o Gentoo. Sabayon e Gentoo instalam todos os softwares dependentes de prefork ou de trabalho, mas enquanto os configuram, apenas aqueles cuja dependência é atendida pelo sistema devem ser executados.
O que é mais atingido são algumas das estruturas baseadas em php (necessárias para sistemas de gerenciamento de conteúdo) que não funcionam. O único framework php que pode rodar no modo itk, evento (e talvez trabalhador) é o cake-php, que infelizmente poucos usam. Acho que mesmo o framework horde (php) mais conhecido também deveria funcionar.
Outra prova de que threads são piores que forks é observar o número de conflitos que dois ou mais adaptadores de servidor web criaram entre si e no sistema, como vemos no Windows.
No caso do Windows, o Apache2 é configurado com o modo de trabalho, pois os modos prefork e itk não são possíveis, mas o modo de evento deve ser muito possível. Portanto, mudar para o modo de evento Apache2 (multithread) deve resolver a maioria dos problemas. Mas o apache2 é muito flexível e personalizável para modperl (e, portanto, perl-catalyst mvc), modpython (e, portanto, django mvc), mas o windows-modruby ainda não está estável, seu equivalente conhecido como modpassenger (modpassenger -- linux, modrails -- windows, locomotive -- macosx) existem em abyss-webserver ou lighttpd-webserver (e, portanto, rails mvc).
A precaução é: Se o sistema for Windows, antes de instalar MVCs de Perl/Python/Ruby/PHP/Tcl, certifique-se de que tudo esteja configurado apenas com um único servidor web - apache2 ou lighttpd ou talvez cherokee. Se você pretende usar rails com abyss, modrails então certifique-se de que a configuração drupal/jhoomla com wamp, modphp não deve estar presente - caso contrário, às vezes o shell padrão do windowsxp pode travar (você ainda pode recuperar usando windowsxp com alternativa- shells como reactos-shell, emerge-desktop, sharp-enviro, bblean-blackbox, etc com gerenciadores de arquivos alternativos como ros-explorer, cube-explorer, ultra-explorer, etc - desde que qualquer usuário não se importe em adaptar e usando o mesmo sistema operacional com um shell de desktop e gerenciador de arquivos com aparência diferente).
No Windows, portanto, os modrails entram em conflito com o modphp (até que um modruby estável esteja disponível), e que o windows-desktop-shell baseado em asp (ambiente de modelo de objeto de rede do Windows) pode conter apenas um de cada vez, enquanto os shells alternativos escritos em blocos de código (reactos e emerge-desktop) não travam, enquanto aqueles escritos em delphi (sharp-enviro) travam parcialmente, mas um remake lazarus do sharp-enviro não deve travar.
Portanto, uma das razões pelas quais a tecnologia web Linux é uma variedade muito maior e ainda assim bem-sucedida é devido às vantagens do modo bifurcado sobre o modo encadeado. A tecnologia Windows Web ainda gira em geral com menos players e algumas poucas tecnologias de código aberto, depois de muito trabalho duro.
Responder4
Apenas algumas informações adicionais, acabamos de descartar o mod_perl no Win32 e mudamos para PSGI usando Plack. Há uma camada de compatibilidade para CGI::Application que está funcionando muito bem para nós. O Catalyst está mudando/mudou para PSGI também.