[SP-pm] MVC correto para um certo problema

[Lucas Mateus]

Bom, acho que eh bastante relevante e dependente do recurso de Hardware
despendido. Não trocaria XML por outra tecnologia devido a compatibilidade
com JS e XSLT.  Mesmo pq nesse  caso o CGI sera usado somente pra fazer
consultas em BD ou similar, nada mais. Existe um painel para administração
de websites com quase 2 milhões de websites, escrito em CGI e Template e
varias outras tecnologias envolvidas, não sei quantas requisições por minuto
recebe, mas acredito ser mais bem mais de 20. A alocação de memória com
mod_perl era inviavel apesar do server ter 8GB de RAM =)   tudo bem
confesso, ele tbm tem 8 processadores Xeon aheuaheuaheuaheuaheuahuehau



Em 06/11/07, eden <edencardim em gmail.com> escreveu:
>
> On 11/5/07, Lucas Mateus <lucasmateus.oliveira em gmail.com> wrote:
> > Acredito numa solução um pouco mais complexa, porem com grande
> performance
> > dependendo da ocasião. Quanto mais camadas se subdivir o projeto melhor
> eh a
> > manutenção. Então meu palpite vai para CGI, XML e XLST, quando seu
> cliente
> > quiser mudar a caretinha do programa ou passar um batom sobra só o XSLT
> pra
> > mexer. Parte do processamento eh despendida para o cliente, a integração
> é
> > boa e a performance excelente !!!
>
> CGI tem problemas de performance bastante conhecidos, o tempo de carga
> é bastante alto porque o programa precisa ser compilado a *cada*
> requisição. Use isso num website com mais de 20 requisições por minuto
> e você vai ouvir o seu hardware implorar por misericórdia. Use FastCGI
> (se quiser economizar memória) ou mod_perl (se quiser economizar
> processamento). Só recomendo CGI em último caso, se for uma
> configuração bizarra que não permita utilizar mais nada.
> Qualquer coisa baseada em XML tende a ser gorda e gera bastante
> overhead de tráfego e processamento. Pra serialização de dados eu
> recomendo JSON que é mais magrinho e tem a mesma flexibilidade.
>
> --
> edenc.vox.com
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/saopaulo-pm/attachments/20071106/bda60942/attachment.html