>>>>> "Carlos" == Carlos Costa <crnco...@gmail.com> writes:
Carlos> Oi Lucas, Aqui no trabalho usamos bastante CGI (criamos Carlos> nosso MVC em cima de CGIs) pq é muito simples de fazer Carlos> deployment. Porque é mais simples? Qualquer framework moderno consegue executar num ambiente CGI/FastCGI out-of-the-box com a mesma facilidade de qualquer outro script escrito em perl. Carlos> No geral o problema que temos é que cada script.cgi roda Carlos> standalone per process no apache, abrindo uma instância do Carlos> Controler.cgi pra atender cada request. Isso implica em Carlos> abrir conexão com o mysql pra popular os models e, Carlos> finalmente, usar templates pra gerar uma resposta. E isso vai estressar rapidamente a sua base de dados. Carlos> FastCGI ajuda a minimzar a demanda de recursos que o CGI Carlos> exige do servidor pois usa processos que persistem ao longo Carlos> de uma serie de requests. Mas mesmo assim, usando processos separados você ainda vai ter problemas, como por exemplo, vai ter um interpretador diferente residente na memória, pra cada arquivo .cgi, quando apenas um interpretador basta. Essa técnica de deixar o apache fazer o dispatch das urls pra você é bem antiga e está caindo em desuso exatamente por conta dos problemas envolvidos com os múltiplos processos. Carlos> Uma outra técnica bem legal pra aumentar o desempenho do CGI Carlos> é fazer cache dos modelos na memória de alguma forma. Vale Carlos> mencached, redis, ou até manter um daemon simples escrito em Carlos> Perl que fique hashes pra vc (ou simplesmente mantendo o BD Carlos> aberto ehehehe). Só que Caches requerem muito cuidado pra não causarem race conditions. Claro que se for pra montar algo minúsculo/não-importante, nada disso é relevante. -- Eden Cardim Software Engineer http://bit.ly/edencardim http://twitter.com/#!/edenc +55 73 9986-3963 =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer