Another J2EE vs .NET Performance Comparison
Starting yesterday, we received a bunch of story submissions about a
performance comparison between J2EE and .Net. It didn't seem all that exciting, and we sort of ignored the story. But as usual, it appears that some people take issue with the methodology and conclusions.
The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue. What should be focused on to support the future of computing is a well-typed, well-structured language to allow programmers to think at a higher level of abstraction than previously. That's why I love Mac's standardization of Objective C so much -- it allows high-level control of programs. Performance only matters if it sucks.
But what do I know. I'm just looking for anonymous gay sex.
...are interesting when well researched, but basically useless to anyone who would actually have to choose between these two development environments. If you work for a company that designs applications of this kind there will be a host of more important things to consider than raw transactions per machine. The simple fact of e-commerce is that if a user is actually going to buy something at your site, you can waste tremendous processing power making them happy. If you make 2 dollars profit on a transaction and had to use 20% of the CPU on a 2Ghz processor for 40 1 second bursts (like you will if they shop using RH interchange), it's still worth it. What this benchmark argues well is that the MiddleWare product is probably worth buying if you have processor constraint problems. No amount of increased performance would warrant changing a staff of experienced Java programmers into a staff of inexperienced .net programmmers. Extra processors are just too cheap....
Did you intentionally reverse the figures? The
Why not go to the source and draw your own conclusion. I looked at the report and it seemed more than fair. This was a straight up "best practices vs. best practices" competition, using Sun's recommended coding standards.
It is helpful to note that this is the second such test that The Middleware Company performed. The Java folks squawked because the
In my opinion you can pin the blame squarely on EJB's. They are bloated, the environments are a royal pain to configure, and they are S-L-O-W. Sun recommends that people use them, so it's totally fair that it was used against them in this comparison.
Hate Microsoft if you want (I do), but you can't wear blinders and ignore the competition. J2EE blows. Get over it.
Oracle did a study showing the reverse with their app server and database.
e t_ bench.pdf
.Net
http://otn.oracle.com/tech/java/oc4j/pdf/9ias_n
In Oracle's study, they achieved results that were as much as 22x faster than
Here's the basic story.
Once upon a time, Sun wrote a sample application, called PetStore, as a demonstration of various capabilities of the J2EE platform, and various techniques that might be helpful when writing J2EE applications. As such, it was deliberately over-engineered. A tiny shopping site doesn't need all the techniques they threw at it, it was just a context in which to deliver examples of coding pratices that might be useful in other situations. It was example code.
Speed wasn't a goal. Keeping the LOC low was counter-productive to an application which is basically an example of different coding techniques.
Microsoft saw this, and realised they had a cheap marketing opportunity. By rewriting the Pet Store in .NET, with completely different goals (speed and low LOC), they could score points just by issuing press releases. It's the marketing equivalent of saying "Hey! Our car is smaller and faster than your truck!" It's true, but meaningless.
No matter that it was an apples to oranges comparison. No matter that the Pet Store could be rewritten in Java using Open Source frameworks with about the same number of LOC by one guy in his spare time. This is marketing, not reality.
Charles Miller
The more I learn about the Internet, the more amazed I am that it works at all.