Dominique Gallot wrote:
Oui.Pour info le review en question http://www2.theserverside.com/home/thread.jsp?thread_id=16149&article_count=254
Ils ont utilis� CMP pour la persistance c�t� J2EE, voil� ce qui peut d�j� tout expliquer. Ainsi que le fait de n'avoir pas utilis� un JDK 1.4, qui est beaucoup plus rapide pour les I/O et le Hotspot.
En outre:
"It appears that different database servers were used for the two tests, and that XA was added to the mix. What were the results with no XA and both running off the same Oracle database server? (apples to apples)"
"I'd also be interested to see this running using CMP2.x. This should result in a massive reduction in LOC, I'd have thought, as well as improved performance."
"Otherwise the difference is indeed significant and it makes me think that of course the C# runtime is deeply connected with the OS core, and purely on Windows-performance criteria Java will never be faster, just because MS is the manufacturer of the OS.
Companies who want pure performance, can afford state-of-the art data centres and J2EE is leading there. Companies that want cheap solutions, can go with JBoss or Perl. The battle will probably be somewhre in the middle."
"Lastly, I'd ask why they didn't use the same database for both applications. Seems to me that the database is a big unknown in this equation."
" this test means nothing until both of them are run with the same database. Otherwise, this could all be 100% database performance and have nothing to do with J2EE or .NET.
The database will have to be Oracle, since the JDBC drivers for SQL Server are slow.
I also think the use of distributed transactions ought to be dropped, since this is not a typical design for stores that need high performance. EJB is a very questionable choice in general, and numerous benchmarks have shown that using straight JDBC in Java classes has dramatically better performance than EJB."
etc... ;-)
Ca d�pend d'�norm�ment de param�tres (ont-ils utilis� un JDK 1.4.1 (hotspot bcp plus rapide), quels tests ont �t� faits?, de quelle mani�re? (overhead JIT de Java), etc...), mais on sait tous ce que valent ce genre de stats ;-)C'est trjs le probleme. Windows (.net) out of the box, ca marche et pas trop mal, le reste cela peu aller mieux, mais quel boulot !
bof, non, m�me pas...
Tr�s int�ressant. Je pense qu'apr�s avoir survol� �a, �a r�pond aux questions et aux doutes ;-))Note que pour ce test entre .net et java il y a une belle critique de ce test sur ce site http://dreambean.com/petstore.html
euh... ?Pour les features de J2EE et .Net, il existe pas grand chose que l'on ne peut pas faire en .Net qui peut etres fait avec J2EE !
Et que fais-tu de:
(x=dans J2EE et pas dans .NET, v=dans J2EE et .NET, enfin... lol)
x JMS = Java Messaging Service (publish/suscribe avec persistance et transactions)
v JDBC... bon, oui, ODBC g�nial, merci lol
x CORBA
x EJB = Enterprise JavaBeans = entit�s serveur avec plusieurs modes possibles:
- Stateless Beans
- Session/Stateful Beans
- Entity Beans, avec avec CMP (Container Managed Persistence) et BMP (Bean Managed Persistence)
(non, ADO.NET c'est pas pareil et COM+/DCOM... you have to be kidding ;-))
x JMX = Java Managing eXtensions, permettant d'incorporer n'importe quelle impl�mentation JMX (p.ex. de JMS) dans n'importe quel EJB-container
v JSP/Servlet = ASP... mouais...
x interop�rabilit�
x choix de l'impl�mentation
x multi-plateformes
Et puis de toute mani�re, .NET est encore nulle part, donc ce n'est pas encore le moment de comparer les technologies.
Pour ceux qui ne me croient pas, allez faire un tour sur Jakarta:
http://jakarta.apache.org
http://xml.apache.org
et JBoss:
http://www.jboss.org
;-)
J2EE *est* actuellement le standard de facto pour les applications enterprise (au sens anglais/IT du terme), et c'est pas demain la veille que .NET va le rattraper/remplacer.
Faut bien voir aussi que microsoft et autres compagnies sponsoris�es par microsoft ont des pr�visions mirobolantes pour .NET, mais il ne faut pas oublier que .NET va remplacer les technologies microsoft *actuelles* (Visual Basic, Visual C++, VBScript, ActiveX, COM, DCOM, ...), mais ne va que prendre tr�s peu ou peu de parts sur les projets/soci�t�s qui utilisent actuellement J2EE.
Le degr� de maturit� est �galement tout autre.
En plus de cela, Sun est d�j� en train de fignoler la contre-offensive avec leur plateforme ONE (Open Net Environment) qui incorpore J2EE + Web Services (qui sont d�j� en cours d'int�gration dans J2EE aussi d'ailleurs) + ...
"When it comes the field that J2EE is for, Microsoft is playing a catchup game. Don't be fooled by claims from any party. It is simple that there is a motivation behind a claim although it may or may not be honest and objective. For instance, why would the midleware company spend time and resources on "J2EE vs .NET Performance Comparison Performed"? The guy in the midleware company knows pretty well that .NET is not even a matured technology. On the other hand, I doubt if you can really be serious about comparing the performance between a language designed to run on many different platforms with one designed specifically for M$ platform. How can you, for instance, compare the speed between a car and a train?"
--
-o) Pascal Bleser http://guru.unixtech.be |
/\\ <[EMAIL PROTECTED]> |
_\_v <[EMAIL PROTECTED]> |
---------------------------------------------|
Jesus saves,Buddha makes incremental backups :
---------------------------------------------'
_______________________________________________________
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux
Archives: http://www.mail-archive.com/[email protected]
IRC: efnet.unixtech.be:6667 - #unixtech
