| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Aconselho a quem quiser a ir ver a discussão no server side (link no fim do artigo). "The Pet Store" nunca foi uma benchmark, mas sim uma demonstração de padrões de desenho. Estranhamente nenhum dos padrões de desenho encontra-se na implementação da MS em .Net (que não passa de um grupo de queries à base de dados "optimizada" para performance). Claro que quem gosta de comparar alhos com bugalhos (leia-se, a malta de marketing) gosta muito destas "benchmarks".
As usual: Lies, Damn Lies and Benchmarks.
|
| | | | | | | Aconselho a quem quiser a ir ver a discussão no server side (link no fim do artigo) Sim, fui ver... mas são centenas de mensagens!!! "The Pet Store" nunca foi uma benchmark, mas sim uma demonstração de padrões de desenho. Mas concordas que o mesmo design pattern implementado em duas linguagens (plataformas) diferentes podem ser testados para ver qual foi o melhor implementado.? Estranhamente nenhum dos padrões de desenho encontra-se na implementação da MS em .Net Quais? E podes explicar melhor? Estás a dizer que o PetStore em .NET não implementa os mesmo desgin patterns que foram implementados em J2EE? que não passa de um grupo de queries à base de dados "optimizada" para performance Podes escrever paragrafos com sentido, e que sejam explicitos, para eu perceber o que estás a dizer e poder concordar ou discordar contigo? Claro que quem gosta de comparar alhos com bugalhos Não me parece que este benchmark esteja mal feito. Mas mais uma vez, vais ter de explicar onde é que as duas coisas são diferentes. Eu analisei o Pet Store .NET e o que vejo é uma aplicação web, bem desenhada... para performance, e que incorpora algumas ideias que são usáveis.
|
| | | | Espremido para quem não se deu ao trabalho de ir ler:
1) A Pet Store de J2EE não é um programa normal. É uma demonstração da aplicação de vários padrões de desenho da arquitectura J2EE. O objectivo da sua construção é puramente pedagógico, sendo mais importante conceitos como escalabilidade e legibilidade do código do que velocidade.
2) A MS implementou uma "Pet Store" em .Net que não tem as mesmas características. Esta está optimizada para velocidade, não escala como a de J2EE (*), nem apresenta as mesmas preocupações de desenho. É portanto um programa completamente diferente.
3) Comparar programas diferentes dá resultados diferentes. Esta estranha conclusão leva a outro resultado interessante: esta comparação só serve para o departamento de marketing enganar papalvos.
PS: Eu não estou a dizer que J2EE é mais rápido. Haverá sempre situações em que um é mais rápido que outra. Existem várias razões técnicas para código .Net ser mais rápido que Java, tal como existem razões históricas para Java ser mais estável que .Net. Mas isso não se prova com benchmarks que comparam maçãs com bananas.
(*) Se comparares os mesmos programas num cluster de 3 PCs, provavelmente a versão de J2EE ganha porque basta o container (como, por exemplo, o JBoss) suportar clustering, enquanto que terias de modificar a versão .Net.
|
| | | | "The Pet Store" nunca foi uma benchmark, mas sim uma demonstração de padrões de desenho. Acho que a frase deveria ser refornulada sim para :
"The Pet Store" nunca foi feita para benchmark mas sim como uma ferramenta de aprendizagem !! A MS cria uma "Pet Store" criada especificamente para benchmark e tenta concorrer com uma coisa feita com um objectivo totalmente diferente .. tipico MS.
que não passa de um grupo de queries à base de dados "optimizada" para performance Isto é um paragrafo com sentido ... o que ele quer dizer é que a Versão da Microsoft foi optimizada para o servidor SQL da Microsoft ( e respectivo sistema operativo ) usando "stored procedures", o que dá um boost significativo na performance.
Claro que quem gosta de comparar alhos com bugalhos Isto é como comparar um carro modificado para provas de automobilismo e um carro para andar a tirar a carta .... A Pet Shop da Microsoft foi criada especificamente para benchamark enquanto que a versão J2EE foi criada para aprendizagem, que apostou na portabilidade em sistemas e base de dados, muito ao contrário da estratégia da MS ( o que já é costume ).
Gostava de ver era um bechmark "certinho e direitinho", usando a mesma Pet Shop da Microsoft mas agora contra uma versão optimizada da J2EE para bechmark e a correr no seu sistema nativo, Solaris com processador UltraSPARC. De certeza que os resultados iriam ser bem diferentes ...
Outra coisa interessante é ver isto ...
|
| | | | obrigado a ambos (aphex e jneves) pela (re)explicação, e só tenho uma coisa a acrescentar: a versão 2 do PetStore, que foi criada após a optimização efectuada ao J2EE PetStore, não usa stored procedures.
Acredito que a Microsoft tenha feito um benchmark sobre algo não inicialmente preparado para tal, mas depois a Sun foi optimizar o PetStore e deu asas a este jogo...
|
| | | | Não dá para apagar comentários?
|
| | | | obrigado a ambos (aphex e jneves) pela (re)explicação, e só tenho uma coisa a acrescentar: a versão 2 do PetStore, que foi criada após a optimização efectuada ao J2EE PetStore, não usa stored procedures.
Acredito que a Microsoft tenha feito um benchmark sobre algo não inicialmente preparado para tal, mas depois a Oracle foi optimizar o PetStore e deu asas a este jogo...
|
| | | | O benchmark do java é o ECperf e não o Pet Store.
A microsoft nunca lançou nenhum benchmark baseado no ECperf para se comparar mas sim novamente no Pet Store :-)
Pedro Esteves |
| | | | A oracle ja vez isso e o .Net apanhou uma tareia.
|
| | | | desculpa te só responder agora mas só agora e que reparei que havia sido posta uma questão, os resultados dos testes seguem abaixo:
http://otn.oracle.com/tech/java/oc4j/pdf/9ias_net_bench.pdf
Para saber mais do codigo utilizado inscreve-te no otn da oracle é gratuito.
|
| | | FUBAR (Pontos:2, Despropositado) |
| | FUBAR
--------------------------------------------
If there is such a thing as too much power...
I've not discovered it.../I |
| | | | O PetStore da Sun foi criado com o intuito de exemplificar a tecnologia J2EE, e consequentemente tenta utilizar todas as API's e funcionalidades do J2EE. Ou seja, muito certamente a solução apresentada é um overkill para resolver o desafio do PetStore.
Recomendo que leiam este artigo :
Review of "The Petstore Revisited: J2EE vs .NET Application Server Performance Benchmark"
Onde se pode ler :
Several independent sources have now confirmed that The Middleware Company was indeed paid by Microsoft to conduct this report.
|
| | | | | por Anonimo Cobarde em 05-11-02 14:15 GMT (#17)
|
| desculpem o copy&paste
http://www.middleware-company.com/j2eedotnetbench/faq.shtml
Was Microsoft involved in this, did they fund this, where were the tests done?
Yes, Microsoft was certainly involved, as the paper describes. The Middleware Company approached Microsoft regarding performing such an experiment. Microsoft provided the lab, which was located in Seattle, funded the setup costs, and reimbursed us for expenses, including travel expenses. The Middleware Company invested several man-months in this project for which it received no compensation. The activity took much long than we expected, and at various points, we also hired independent consultants experienced in appservers A and B to tune them or provide recommendations, at our own expense. The parameters of the lab were under the control of TMC. TMC controlled the testing process. TMC stated up front that TMC would write a report about the real results, no matter what they were. These experiments are time-consuming, and require resources. Without permission and some support from Microsoft, we would not have been able to conduct the experiment. We would like to have conducted many more experiments than we did, and hope to in the future. TMC stands behind the results of the tests that were conducted.
Does the fact that Microsoft gave permission for this experiment and provided some support, invalidate the results?
That is for you to decide. TMC stands behind the results of the tests that were conducted. Should there be other such experiments to be arranged in the future, we will not be able to do them without some assistance with the lab, setup, expenses, and we would hope for more support than Microsoft provided us with for this experiment.
The report states that a Microsoft employee was allowed to tune the .NET app. Were vendors of appserver A or appserver B involved, to tune their own appservers?
No they were not. We are currently working to conduct a different experiment where all the vendors do participate.
If you were to run the app on appservers A and B without using EJBs as many TheServerSide.com members have suggested, would it not run as fast as or a little faster than the .NET app?
It very well might have. We don?t know. Some of us think that without EJBs the J2EE app would have clearly beaten .NET, but others who feel that for this particular app, the .NET version would have beaten the J2EE version even without EJBs. We may conduct this experiment in the future.
Are you guys saying that this was the best possible application architecture and code to perform such a test?
No, as one would expect, it leaves a lot to be desired. It is an extremely challenging task to come up with such an application that everyone can agree on. That is why standard bodies exist, and there are some (e.g., the standards body that came up with ECperf, now called jAppServer ? see question below) that have done an amazing job with this process. Because it is so difficult, it takes years for these evolve, though.
Why did you not use jAppServer benchmark (formerly ECperf)?
That is absolutely what we would have preferred to do, and wanted to do in the first place. And we would really like to do this eventually. However, jAppServer is not available on .NET. We considered porting jAppServer to .NET but it would require a huge number of man hours, and the licensing arrangement prevents it. We may pursue obtaining permission to do this. With the old version of PetShop available, we had a head start.
After reading this benchmark I don't trust TMC's or TSS's advice anymore.
TMC had a lot of heartache seeing the results of this benchmark. We internally debated about whether we should post this or not. In the end, we decided to go forward and publish this report.
TSS decided to post this news item, since TSS' commitment to the members of this web site is to publish all the facts, even if those facts are sometimes not positive about J2EE, so that we as a community can improve. As far as whether you trust us or not, I think I will leave that up to the community to decide.
|
| | | | O Pet Store foi uma aplicação criada pela Sun apenas com motivos puramente pedagogicos, para explicar o funcionamento do J2EE.
O que a Microsoft fez foi agarrar nessa aplicação e rescrevela totalmente em C# a pensar simplesmente no benchmark.
O seu codigo apenas corresponde a 1/4 do tamanho do codigo da aplicação original (e não foi porque o C# é mais simples e eficaz, simplesmente porque o java da aplicação original foi escrito para ser legivel por toda a gente e não para ser pequeno e eficaz).
Segunda questão. Quando a Microsoft reescreveu a aplicação modificou todos os seus fundamentos, principalmente no middle-tier e no acesso á base de dados, coisas que não tem nada a ver com a plataforma .NET, nomeadamente.
i) modificações dos queries SQL para retornarem menos informação;
(ii) Substituiram "join queries" complexos por simples queries de uma só tabela.
(iii) Meteram os SQL queries na base de dados usando "stored procedures".
Em suma a aplicação é outra completamente diferente. São estas pequenas modificações que o publico não percebe nem se interessa.
O Pet Store apenas foi usado (pela Oracle) num benchamarl simplesmente porque o ECperf ainda não estava terminado.
Pedro Esteves |
| | | | | Dada o aceso feedback em torno desta questão, já se está a pensar num rematch. :) A number of good ideas have surfaced. Here are some of the options we are considering. This list may grow for a couple/few days after which we need to begin deciding which option to pursue. If you have specific viable scenarios in mind, please tell us. Alguém quer participar?
A minha anterior assinatura era ainda pior que esta. |
| | | | | | O problema é que já houve um aceso debate em torno desta questão há um ano atrás, por alturas do primeiro Pet Shop. Embora concordando com os argumentos de então que, na prática, não era uma aplicação para benchmark, a verdade é que esta segunda versão já foi desenhada para tal. Mesmo assim o J2EE foi batido e não foi por pouco. Até meteu dó. Acham mesmo que é uma série de desesperados a tentar optimizar o código, os application servers e a DB que vai trazer o Pet Shop Java para níveis semelhantes ao .NET? Eu duvido. E mesmo que tragam para níveis semelhantes isso será suficiente? Relembro que o desenvolvimento em .NET foi bem mais rápido e barato e assim há-de continuar a ser. Pior que um cego é aquele que se recusa a ver...
|
| | | | Quem? (Pontos:1, Despropositado) |
| | J2EE? .NET?
I have PHP so who cares about those...
|
| | | | | | Pondo de outra maneira...
(Better performance + Fewer lines of code) != J2EE
(Better performance + Fewer lines of code) != .NET
(Better performance + Fewer lines of code) != Anonimos Cobardes que submetem propaganda M$ e depois enfiam "despropositado" em quem não concorda
(Better performance + Fewer lines of code) == PHP
Tá melhor assim? :]
|
| | | por Anonimo Cobarde em 05-11-02 18:19 GMT (#22)
|
| <sarcasmo>
o que se vê realmente mais por aí é middleware e aplicações feitas em PHP!
</sarcasmo>
o propósito do PHP é a web.
|
| | | | Eu nem costumo responder a cobardolas mas como nem tu, nem a pessoa que anda neste thread a moderar ao contrário sabem ler, eu passo às quotes.
New .NET Pet Shop 2.0 Reference Application for Scalable Web Applications
o propósito do PHP é a web.
Ainda bem que não estamos a falar de uma aplicação Web! Senão até podias ter razão!
middleware PHP? só porque não vês não quer dizer que não exista... é que apesar de tudo, nem toda a gente tem a "honra" de aparecer numa "comparação" M$.
apps em PHP? Haver, até há... mas dá-lhes uns tempos e até tu às vais ver...
|
| | | | Em primeiro lugar a Middleware Company foi paga pela Microsoft para conduzir este teste. Para quem não sabe foi usado o petshop 2.0 da Microsoft e a Middleware reescreveu o Petstore da SUN
Bem agora algumas coisas mais tecnicas para os puristas do Gildot :-)
Em primeiro lugar a versão que a Middleware usou do Petshop foi baseada na 1.1.2 escrita á 2 anos . Em vez da mais actual 1.3.1 que usa CMP, local interfaces, e cache.
Em segundo lugar as linhas de codigo enquanto a aplicação J2EE tem cerca de 14000 a .net tem só 2000. O que a Middleware se esqueceu de dizer é que na aplicação java os metodos como o getConnection(), são repetidos em todos os Beans e que a aplicação é toda muito mais Verbosa ( para ajudar os principiantes). Alem disso á um monte de classes e metodos que não são usados para nada e que a Middleware deixou ficar.
Quanto á optimização é outra palhaçada. Foram usados BMP EntityBeans em vez dos actuais CMP EntityBeans o que influencia em muito a performance. Sem falar da falta de optimização dos Servidores de aplicação A e B (WebLogic e WebSphere). Só no Weblogic da BEA se tivessem usado o Workshop em vez de usarem os Web services directamente ganham um aumento de 30 vezes mais.
Conclusão: A microsoft pagou à Middleware para fazer uma aplicação de java mal feita e mal implementada e comparar com as sua aplicação 100% optimizada.
Se quizerem ver mais dados tecnicos -> http://dreambean.com/petstore.html
Pedro Esteves |
| | | | | por Anonimo Cobarde em 05-11-02 15:42 GMT (#20)
|
| A ver pelos comentários no site parece que existe sim uma grande frustração em relação a tudo isto. E o facto de os principais fabricantes não se envolverem diz muito em relação à confiança na performance do J2EE.
O argumento agora resume-se à "Portabilidade" mas mesmo este parece não fazer sentido quando cada fabricante implementa serviços diferenciadores, por exemplo o CMP.
Uns querem oferecer dinheiro a quem "conseguir" melhor a performance desta implementação em 10%, outros começam a abrir os olhos:
“From Java to J2EE to Oblivion”by Jonathan Gibbons has stirred up a lively discussion thread on theserverside.com
The sentiments of the author, an experienced J2EE developer/architect, reflect that J2EE is turning out to be much more complex than advertised. Development is slower than predicted, the tools are weak, and the inefficient community process to supply missing pieces (XML, mobility, smart client) is becoming an issue. And although Java bigotry and anti-MS sentiments abound, there is a distant drumbeat telling J2EE developers that they’d better start learning .NET because it’s coming on strong.
|
| | | | "J2EE is turning out to be much more complex than advertised"
Nunca niguem disse que era simples. Java é uma linguagem complexa e ainda se torna mais trabalhando com o J2EE framework e os aplications servers. Não para os meninos do VB+access que abundam por ai e que estão a iniciar-se no .NET.
"they’d better start learning .NET because it’s coming on strong."
Lá porque toda a gente usa Windows e Visual basic não quer dizer que seja bom. Provavelmente o .NET vai servir para soluções mais simples e menos complexas. Exactamente como o windows vs Linux/Unix. Provavelmente vai haver no futuro mais gente a usar o .NET do que o J2EE como existe neste momento mais pessoas a usar o windows que o Linux/Unix mas isso não quer dizer que seja melhor.
Pedro Esteves |
| | | | Epa é claro que já exprimentei o .NET embora não tenha implementado nada sério com ele. É claro que o .NET tem coisas bastante bem feitas. Niguem está dizer que o .NET não presta.
O que não presta é a tactica de markting da Microsoft de comparar coisas que não tem nada a ver só de modo a promover o seu produto.
"As we have seen, Microsoft's involvement in this matter goes far beyond just providing a test lab and reimbursing travel expenses,"
"They are the initiator of this whole project (as described in the TMC FAQ), have cheated to the point where their code does not even comply with the basic rules of the test, and have obtained the results of this report far ahead of its official publication. Since I believe most of my readers are quite intelligent, I will let you draw your own conclusions about what all of this means,"
http://www.theregister.co.uk/content/4/27929.html
Pedro Esteves |
| | | | Outra coisa que mostra a palhaçada do benchmark é o facto de fazerem aquilo correr apenas num server... quando um dos pontos fortes do J2EE é a sua eslabilidade e facilidade de ser distruibido.
|
| |
|
