Benchmarks PHP x Grails
05/04/2012 23:29
1
Numa iniciativa pessoal foram comparadas as performances e consumo de memória e CPU do PHP (framework Symfony 2.0).

Os resultados do Grails foram MUITO superiores aos do PHP:

http://cutiecode.maniacmansion.it/post/2378498792/grails-vs-symfony-2-0-benchmark


Dai, num fórum um rapaz lá questionou se uma tal de funcionalidade de 'cache APC' estava ativada. O responsável pelo teste disse que não mas que iria refazer os testes. Resultado: Nova goleada do Grails, apesar da leve melhora do PHP.

http://cutiecode.maniacmansion.it/post/2777523715/grails-vs-symfony-2-0-with-apc

Fonte: http://grails.1312388.n4.nabble.com/Symfony-2-0-vs-Grails-benchmark-td3094892.html

Comentários

Sabe, neste caso, acredito que o mesmo resultado seria obtido com uma aplicação Java EE tradicional. No final das contas, este benchmark serviria mais pra mostrar que o mito "Grails é lento" trata-se de uma balela (o sistema Grails Brasil prova isto diga-se de passagem).

O que temos de lembrar aqui é que o modelo de processamento entre os dois tipos de plataforma são bastante diferentes. No caso do PHP, temos script na sua forma mais pura (posso estar falando bobagem, aviso). Não há muito este negócio de um singleton durar meses, ele apenas é instanciado e, dentro daquele contexto, mantido durante a execução do script. Isto causa um certo overhead.

No caso da plataforma Java EE, nós não temos isto. O Grails Brasil, por exemplo, está executando sem paradas a exatamente seis meses. Os singletons não são criados a cada requisição. Consequentemente, temos aqui uma escalabilidade bem melhor.


Eh, sou um cara de php, que por acaso se aventurou em um projeto Grails .. acho que esse comparativo apresenta falhas ..

Achei interessante a parte da memória, no primeiro caso foi bem equilibrado. Já nos seguintes nao entendi a disparidade

Mas, quando chega a CPU, é normal chegar a 100% por que o php é um processo que starta durante a requisicao, e quando termina a requisicao o processo encerra.

Consumo de cpu não tem nada haver com tempo de resposta (ser mais rápido). O php respondeu para o usuário mais rápido ou não?

Se ele tivesse configurado para o php usar menos cpu, será que o php teria sido mais devagar?

Seria interessante ele mostrar a média do tempo de resposta

Já sobre escalar ou nao, nao entendi o que o consumo de cpu tem haver. O java tem uma VM rodando o tempo todo, como o kiko disse, mas o php nao gasta memoria nem cpu quando não é requisitado. E outra, o consumo de cpu é do apache ou php?

Observe que o tempo todo não comparei o framework usado .. por que o comparativo é de tecnologias. Será que outro framework teria resultados mellhores? E olha que o symfony nao está entre os framework mais rápidos de PHP.

Resumindo, o benchmark é bem tendencioso, e as análises estão incorretas.

E eu nem falei das configuracoes do php, nem da VM (qtde requests, uso de memoria, etc) :)

Se o grails for mais rápido, consumindo menos recursos, em algum aspecto .. ótimo, mas isso não significa que ele seja melhor ou pior que o php.


Benchmarks em sua maioria são tendenciosos e muitas vezes (maioria) feito por pessoas que conhecem mais uma ferramenta do que a outra.

Também vim do PHP e gostaria de ver um Benchmark com o Zend, talvez fosse o mais correto.

Sinceramente, ainda assim acho que o GRails levaria a melhor por conta de todo aparato da JVM.

Mas independente disso, não tem essa de melhor ou pior. Só que eu não trocaria um Projeto GRails hoje por PHP, inclusive estou pensando em migrar algumas coisinhas que tenho em PHP, tendo em vista a produtividade e poder da JVM que o GRails me dá.

Abs []
06/04/2012 19:02


Existe um framework em PHP estilo GRAILS, o YiiFramework. É bala.
26/04/2012 19:02


 

Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto