Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Another J2EE vs .NET Performance Comparison 533

Posted by michael from the mine-is-bigger dept.
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.
This discussion has been archived. No new comments can be posted.

Another J2EE vs .NET Performance Comparison More

Another J2EE vs .NET Performance Comparison

Comments Filter:

  • Some of us (Score:3, Insightful)

    by Anonymous Coward on Wednesday October 30, 2002 @12:40PM (#4565586)
    Some of us are not in a position to dictate policy. Love Linux or not, some of us will have to use .Net or look for another job.

    Not a good option during these bad economic times.

    • It's not about loving Linux. It's about loving Freedom (TM). And that means not having a centralized conduit for information exchange. It means my computer being mine.

      On a side note, I wish the 'net were never called the 'Information Superhighway.' That single analogous dubbing has spurred the acceptance of rhetoric in Congress that allows all sorts of regulation.

      • It's not about loving Linux. It's about loving Freedom (TM).

        Realistically, though, we're talking about internet application development platforms here, not basic human rights. Being all high and mighty about not uing .NET is trifling at best, to say the least.

    • Re:Some of us (Score:2, Insightful)

      by Anonymous Coward
      Astroturfing.

      Ever wonder why MS is putting .NET ads on Slashdot?

      Well, posts like these are the other shoe dropping.

      Rest assured, many many many companies are evaluating MS technologies vs. OSS technologies for a number of good reasons; Security, reliability, scaleability, non lock-in, no subscription plans, etc.

      For example, see the story posted on Slashdot just yesterday [slashdot.org] where the US DoD is advocating the use of FOSS (Free & Open Source Software). Read the report and the recommendations.

      What's remarkable about this report is that it's written by Mitre and DISA (Defense Information Systems Administration), both very conservative groups when it comes to new technologies.

      I'm posting anonymously because my employer has close ties with MS and after what happened to Bruce Perens for speaking his mind...

  • Performance isn't most important (Score:4, Interesting)

    by Faggot ( 614416 ) <<moc.yag> <ta> <sdaohc>> on Wednesday October 30, 2002 @12:43PM (#4565613) Homepage
    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.
    • Actually languages still continue to matter a great deal even now. While computers are getting ever faster, do you really want to offset speed gains by using languages that are inefficient for many tasks?

      Don't get me wrong. I love high-level languages. Python is one of my favorite languages. However, I would not ever consider doing driver implementation or operating system work in python. Something must be said for low-level languages and their ability to relate directly to the hardware they are running on.
    • Uhh...

      Performance is an issue in enterprise applications. The difference between buying 50 servers and 100 servers matters.

    • Re:Performance isn't most important (Score:5, Insightful)

      by Twirlip of the Mists ( 615030 ) <twirlipofthemists@yahoo.com> on Wednesday October 30, 2002 @12:53PM (#4565715)
      (Given your user name and other info, I expected a troll. Turns out you said something reasonable. Weird.)

      What you say is true on the desktop, but this comparison is between two server technologies. Desktops are fast enough these days for what we want to do with them, but servers are still often heavily overloaded. If you build a big n-tier web application, chances are it's for a commercial purpose, right? So your goal in life is to get more and more people to use that web application, so you can make more money and whatever whatever. If your application can't scale as far as you need it to, it's bad, bad. So performance is very important in situations where the size of the application user base needs to scale dependably.
      • Web Servers tend not to be expensive machines. A decent software engineer is going to have a loaded cost of somewhere in the neighborhood of $150k/year, a good one will be more than that. If I can keep from hiring two of these people by buying $300,000 in hardware, I'm even money in year one, and saving $300k/year every year afterwards.

        People on slashdot have some really, really odd ideas about what's expensive and what's not. Here's a clue: web servers are not expensive.

    • But what do I know. I'm just looking for anonymous gay sex.

      Wait, let me get this straight (no pun intended) -- you're a gay man who says "performance" isn't important.

      Christ, next thing you know you'll be saying that size doesn't matter!
    • The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue.
      You really think people upgrade their hardware so that lazy programmers can get away with sloppy inefficient coding? Not for me, thanks anyway.

      By the way, there is nothing wrong with high-level languages, au contraire. Just use those with efficient [cons.org] native-code [ocaml.org] compilers [gnat.com]. (Objective C in its half-smalltalkness may be nice as well, but personally, I don't really like it.)

    • It's the query that matters (Score:5, Insightful)

      by vanguard ( 102038 ) on Wednesday October 30, 2002 @01:04PM (#4565832)
      I've been building web applications since 1997. In nearly every app I write most of the time is spent gathering and sorting the data, not in presenting the page.

      If one of my pages takes 7 seconds to come up, I can almost guarentee that the query is 6.x seconds. For that reason, I agree, language speed isn't that critical to me. What matters is: How easy is it to write/maintain? Will the language be supported? Can we hire guys that know it? Is it hard to learn?

    • Re:Performance isn't most important (Score:4, Interesting)

      by SirSlud ( 67381 ) on Wednesday October 30, 2002 @01:05PM (#4565848) Homepage
      Patently untrue. Microsoft is FUD-dy, not stupid. They wouldn't be touting performance reports if it didn't matter to purchasers and adopters.

      Whether or not it _actually_ matters is a whole other ball of wax, but I contend it still does. We're not a big business by any stretch of the imagination, but we need 20 servers to handle the load we do (400-600 'requests' per secondwith each request resulting in anywhere from 2 to 4 additional connections made for each request generated) .. if we ever moved to .NET or J2EE, you can bet your ass performance would be a big issue in making our selection.

      You might try rewording: In the *majority* of cases where people are selecting platforms, performance is not always the #1 issue.

      That might approach the truth, but to say performance only matters if it sucks assumes you can afford the hardware to meet your demand with room to spare on the first day you go live. In enterprise applcations (lots of customers) and high load applications (less customers but each customer generates tons of load - like an ad server), performance is _exactly_ where you're going to make or break your ability to supply the demand without buying the Noah's Ark of hardware.
    • The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue

      Troll, troll, troll... I write server applications for living. Performance is absolutely critical to customers because it translates directly into money. Enterprise servers are usually running near peak thruput, making something to perform twice as fast means that the customer needs to spend just half the money (which is often hundreds of thousands of dollars) on their servers.

    • Re:Performance isn't most important (Score:5, Insightful)

      by fusiongyro ( 55524 ) <faxfreemosquito@nOSPam.yahoo.com> on Wednesday October 30, 2002 @01:16PM (#4565963) Homepage
      I completely agree. In fact, that's why Python is my language of choice--I get more done faster, and unless I write a shitty algorithm I really don't notice a speed problem.

      However, when it comes to this particular benchmark, it has more to do with performance on a server somewhere handling thousands of simultaneous connections. Web applications, if you will. And in this particular case, a performance difference of 10% could mean a hundred users get locked out, and responsiveness to the others will be very bad.

      If you ask me, it's one of the great mysteries of the computer industry why desktop apps are written in C/C++ and web apps are written in Java, Perl, or .Net. After all, we've been admitting for years that scripting languages are OK unless you need the extra performance, and these guys do need that extra drop. So why aren't they writing these programs in C or C++? :) Clearly it isn't the libraries or types involved, since these are almost always available to C or C++ also.

      That's the $15 million dollar question, now isn't it? We seem to optimizing for RAD and performance, rather than just performance. Perhaps we should rethink our priorities, move scripting languages onto the desktop, and compiled languages onto the server...

      --
      Daniel
    • Point of clarification for the ignorant.

      J2EE is not a language. .NET is not a language.

      Objective C is irrelevant in this comparison.

  • J2EE (Score:3, Informative)

    by Anonymous Coward on Wednesday October 30, 2002 @12:44PM (#4565620)
    We used all java technology on www.bayoubid.com [bayoubid.com] and had no problems with speed. In fact from our initial tests java was quicker than C#.

  • Hmmmm. (Score:4, Insightful)

    by The Bungi ( 221687 ) <thebungi@gmail.com> on Wednesday October 30, 2002 @12:45PM (#4565636) Homepage
    So essentially this boils down to actually, that thing we said was killer in fact sucks, so your comparison is unfair. We also ain't fixing it, so there.

    I mean, "...excessive exception handling"? WTF?

    This only underscores the by now expected knee-jerk reaction these types of pissing contests bring. There's always some expert who can refute every single point of the whitepaper, who in turns gets dissected by someone else ad nauseaum.

    In the end it's never been about benchmarks or raw speed. It's about how productive you can be writing these applications, time to "market" and total cost. It doesn't matter if J2EE is 14.3% faster than .NET or viceversa.

    • Actually, in this case, it's pretty much about benchmarks and raw speed. Unlike a personal desktop computer or a desktop application, when you're programming an enterprise app your own productivity isn't what's important. The overall reliability and quality of the finished app is what's important. If you choose an enterprise framework that doesn't scale-- or that doesn't scale as well-- then you're in a bad spot. So it's important to know how these two frameworks compare so you can make an educated choice at the front end about which one is better to use. All other things being equal, the faster one is better.

      Of course, in this situation all other things are most definitely not equal. If you want to deploy your enterprise app using a non-Microsoft OS, or if you want to avoid licensing fees for app servers, Java is pretty much your only choice. (Unless you go with a different type of framework altogether, like PHP or something like that. In some cases that's okay.)
    • In the end it's never been about benchmarks or raw speed. It's about how productive you can be writing these applications, time to "market" and total cost.

      And freedom, don't forget freedom.

      Oh, wait. It has never been about that.

  • Paid for by MS (Score:4, Informative)

    by Anonymous Coward on Wednesday October 30, 2002 @12:48PM (#4565661)
    Several independent sources have now confirmed that The Middleware Company was indeed paid by Microsoft to conduct this report.

    From second article.
    • Not exactly. TMC explains it in their FAQ [middleware-company.com].
      • From the FAQ:

        > Does these results mean that J2EE is slower than .NET?

        > No. The results mean that .NET was higher performing than J2EE in this particular comparison. Other comparisons could be conceived where results would be different.

        LOL. First question in FAQ says "BTW, this has nothing to say about whether or not J2EE is faster than .NET"

        Or, slightly reworded: "We published this report for free advertising in the hopes that most people wouldn't make it through to the FAQ, where we admit we're simply riding on the back of the popularity of the J2EE/.NET conflict."

        Considering the amount of non-ideal conditions they recognize invalide the objectivity of the study (they list several in their FAQ), what possible other reason could they have had for releasing it other than to cash in on the ensuing flame wars?

    • Re:Paid for by MS (Score:2, Informative)

      by ruiner13 ( 527499 )
      I noticed that too. Funny thing is, being a Java developer myself, I looked at those benchmarks and came to the same conclusion. We run J2EE servlets and beans on a 350MHz machine and we have not had any performance problems. I smelled something fishy. Then I read the second article and busted out laughing when it said:

      "Several independent sources have now confirmed that The Middleware Company was indeed paid by Microsoft to conduct this report."

      My instant reaction was... "Well DUH!" At least they didn't make up someone who used that as their reason for switching...

      • Reading is goood....mmmm kay (Score:5, Troll)

        by malakai ( 136531 ) on Wednesday October 30, 2002 @01:19PM (#4565998) Journal

        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.


        It's not a loss of face to admit in this particular architecture, .Net beat J2EE. It does not mean .Net is better overall. All this simply states is the obvious, .Net is at least as fast as J2EE when engineered correctly. Both platforms are as slow (or fast) as the architecture decisions made during development.

        I don't understand why people instantly get defensive and point out conspiracies. They both kick ass, use which ever one makes you happy.

        -malakai

  • Hot News Flash -- Java Slow! (Score:5, Funny)

    by duck_prime ( 585628 ) on Wednesday October 30, 2002 @12:49PM (#4565667)
    Thank you, Middleware Company, for that shattering piece of journalism.

    Oh yeah, we are also shocked -- shocked! -- to find out that Microsoft engineers are capable of putting out a rigged demo.

    These are not the benchmarks you're looking for. Move along.

    • Re:Hot News Flash -- Java Slow! (Score:4, Insightful)

      by Thomas Charron ( 1485 ) <twaffle@gmEULERail.com minus math_god> on Wednesday October 30, 2002 @12:57PM (#4565755) Homepage
      Well, I'm going to be written off as a paid Microsoft employee for suggesting this, but..

      I've done some fiddling of some rough benchmarks myself..

      This isn't really a .NET thing here. It's more a demonstration of the speed and bloat associated with doing things in the J2EE way.

      It's not a BAD way to do it. Just as CORBA isn't really a BAD way to handle RPC calls. It's just rather large and has significant overhead.

      The numbers presented actually look pretty much on par, although my local fiddling only went to the extent of using 10 clients connected to the network to beat on the machines..
    • Rigged demo? Please tell us what was rigged? Microsoft sent in an engineer, and a number of well-trained enginners were brought in (for a lot longer period of time than the 2 weeks spent by the Microsoft engineer) to optimize the A and B servers running Java.

      Of course Microsoft will be happy about the results, but think of it this way: Why would Microsoft have spent the money to build .NET if it was going to be slower than Java? Of course they know it's faster and wouldn't have ever done their original Pet Store comparison if they didn't have a margin of victory.

      So let me ask you this: Where is the comparison that shows Java being faster?

      Let me also ask you: Who would decide not to use Stored Procedures if they were available?

      • If you'd read the criticism, the Microsoft app claimed to be a compartmentalized 3-tier system. Apparently it was not. That much is at least under MicroSoft control.

        The other part that seems rigged, but less directly attributable to MicroSoft, is what sounds like really poorly coded J2EE. I'd really never consider paying TMC for any services, given their claim of expertise and the mistakes made in "fully optimizing" the J2EE version of the app.

  • Quel suprise (Score:5, Insightful)

    by JonK ( 82641 ) on Wednesday October 30, 2002 @12:49PM (#4565670)
    ...as all the JavaBots leap to Sun's defence.

    One of the more interesting lines of commentary attached to the original article on TheServerSide was that "the community" should all band together and build a version of the Pet Shop which'd run faster in fewer LOC and on less hardware than the .Net equivalent while keeping to Sun's recommended best practices, thereby demonstrating the overarching superiority of Java and open source (or something like that.

    Or, alternatively, they could choose to sit with their heads in the sand and spread fud about how Microsoft bought The Middleware Company, while waiting for the .Net train to run them over.

    Sun shills, Microsoft shills, what's the difference?

    • One JavaBot's Reply (Score:5, Informative)

      by FortKnox ( 169099 ) on Wednesday October 30, 2002 @01:07PM (#4565870) Homepage Journal
      From the Benchmark FAQ [middleware-company.com]:
      No Local Interfaces were used, so it wasn't a truely 'apples-to-apples' comparison. Local Interfaces make a huge difference (although, they claim to of not seen one in another container).
      They used the latest .NET technology, but didn't employ EJB2.0. But, what's worse, is that they used Entity beans. .NET used a stateless model, but they didn't do the same thing with the Java app.

      I'm not going to tell you J2EE is faster, but I am going to say that they did a lot of apples-to-oranges comparisons and not note them (except in the faq).

      • Re:One JavaBot's Reply (Score:2, Informative)

        by JonK ( 82641 )
        And, as they say in the FAQ, one of their app servers didn't support EJB 2.0, so all the wailing and gnashing of teeth and rending of clothing from the JavaBots is largely irrelevant - if it don't run in the real world, it doesn't matter how great it would theoretically be

        . And, as the FAQ you've so kindly linked to points out, any competent app server will make cross-component calls between components in the same process as in-process calls - thereby negating the main marketectural advantage of local interfaces. Like TMC say, they've done the most apples-to-apples comparison they can, but, again as they point out, there are always going to be problems where the zealots can point out the differences.

        But hey, I'm a C++Bot so I can play disinterested observer. But I will tell you that C++ would be faster, safe in the knowledge that no-one's going to be going to the effort to put that benchmark together ;-)

  • Final Conclusion (Score:4, Funny)

    by Anonymous Coward on Wednesday October 30, 2002 @12:50PM (#4565683)
    The only things TMC actually proved are that they are

    NOT J2EE experts

    but they

    ARE MS shills.

    Everybody knows "benchmarks lie" as the old cliche goes. It's just funny that a chest-thumping "enterprise software" consultancy would so blatantly pitch a relatively un-scientific benchmark as a serious study.

    • Re:Final Conclusion (Score:4, Insightful)

      by truth_revealed ( 593493 ) on Wednesday October 30, 2002 @02:42PM (#4566908)
      Why on earth would Sun put out such a horribly performing example J2EE program (Pet Store) when it knows damn well that 99% of the programmers out there will copy this program as a shining example of how to code in J2EE correctly?
      For God's sake, Sun - get a clue! Give the world a better official J2EE example!
      The J2EE optimization rebuttal seemed awfully complicated to expect a new Java programmer to understand.
      Nevermind benchmarks optimized by experts - average shops don't have such experts. Think about the lowest common denominator. I'd rather see a benchmark of how average systems perform when designed by novices as an indicator of how good the underlying technology is. If a system has to be designed by leading experts then it is not cost effective for the average shop and I would want no part of it. Object orientation be damned - just give me something that works and does not cost an arm and a leg to extend and maintain.

  • Much more interesting - a leaner JPetStore (Score:5, Informative)

    by slamb ( 119285 ) on Wednesday October 30, 2002 @12:52PM (#4565694) Homepage

    jPetStore [ibatis.com] is worth checking out. These people decided that the J2EE pet store is way too complex, which I'm inclined to agree with. They produced, using Jakarta Struts, a Java pet store web application that is much leaner. It's comparable in size to the .NET pet store but better in several ways - there's no SQL embedded in the code, there's no HTML embedded in the database, no code was automatically generated, and it's MVC-based.

    I've always thought that Enterprise Java Beans are overengineering to the extreme. It's nice to have something to back that up with now. There's no question in my mind that this JPetStore beats out both the original J2EE one and the .NET one in maintainability.

    They didn't do any benchmarks - performance wasn't what they were going for - but it would be interesting to see some. I'd be inclined to believe this simpler approach would also have much better performance than J2EE.

    • yes, comparing a lightweight struts/JDO impl running on Jetty would be more interesting.

      I think sun have got into a mess pushing EJB as the be-all and end-all of server side java coding. I dont know whether that was because they wanted to enable client server apps using the EJB api too, justify to customers the purchase of premium j2ee servers over free servlet engines, or encourage sales of multiway solaris boxes.

      But because EJB is wierd, ugly and so limited, I dont think it is the right design for many apps. The fact that it can take weeks of 'tuning' the app server to get acceptable performance out of it is a fatal flaw in its own right. nobody has time to do that.

  • Price/Performance page 25 says it all (Score:5, Insightful)

    by Pov ( 248300 ) on Wednesday October 30, 2002 @12:52PM (#4565699)
    Regardless of how you argue the testing parameters, it's pretty clear the .NET implementation won out. Even if it didn't, the Price/Performance chart makes this a pretty easy pick for most businesses.

    You can probably get much higher performance out of the J2EE stuff at the very top end, but only by running it on the 'big iron' that most companies can't afford and even fewer actually need.

    M$ has a lot of problems, but this .NET stuff is cool and people should take notice. Even the evil empire can raise the bar. And competition helps us all in the end. Lower those prices SUN and Oracle!!

    • Re:Price/Performance page 25 says it all (Score:5, Insightful)

      by steve_l ( 109732 ) on Wednesday October 30, 2002 @01:13PM (#4565924) Homepage
      That's what comes of BEA and WebSphere pricings; if they'd used jboss or HP-app server (still a free download, I believe), app server cost becomes zero, leaving only hardware, OS and database. Move to hypersonic SQL or postgres to take oracle out the loop and you start to get economic performance. Sure, per-cpu perf may be less, but what if all those CPUs are just blade mounted PIII-8000 parts running your favourite linux distro?

      NB, after development costs, the biggest expenses in my last projects were operational costs and hardware depreciation. This review didnt look at either of those, but everyone I know is scared of IIS management, so its operational cost is probably higher.
      • That's a very good point, but a difficult sell to management. From my experience if management gets sold on J2EE or anything Sun related, they swallow the whole damn load.

        The companies I've worked for have never had much trouble with IIS (maybe just lucky if you believe what you hear around this site) and they are definitely cheaper labor. .NET is very easy to code with and it's very fast to develop in. That's why I would go that way, but there are always good alternatives.

  • Starting off strong (Score:3, Funny)

    by sootman ( 158191 ) on Wednesday October 30, 2002 @12:53PM (#4565704) Homepage Journal
    Quote from the article: It contains both errors, halftruths, and lies.

    Unfortunately, the article contains both spelling errors, grammatical errors, and errors of style.

  • hmm... (Score:3, Funny)

    by SpanishInquisition ( 127269 ) on Wednesday October 30, 2002 @12:54PM (#4565725) Homepage Journal
    this is like trying to make a race between a tortoise and a snail, only to realize that your stopwatch doesn't go over 15 minutes.

  • J2EE, EJBs vs "JSPs" (Score:3, Interesting)

    by kisrael ( 134664 ) on Wednesday October 30, 2002 @12:55PM (#4565727) Homepage
    I've heard some word (admittedly not many datapoints) that some companies are still embracing Java/J2EE, but are going for "JSPs" (hopefully a euphamism for good use of regular java objects, maybe some wrapped JDBC) instead of the fullbore EJB. In my experience, this is a very smart thing. I've had successes with using a lot of the same patterns recommended for EJB with the lighter-weight stuff, and have heard of at least 3 really collosal EJB failures.

    EJB makes it easier to have physically seperate tiers, and adds enough systems-needed overhead that you'll probably need 'em...

  • Benchmarks for tasks with N-number of variables... (Score:4, Interesting)

    by Art Popp ( 29075 ) on Wednesday October 30, 2002 @12:55PM (#4565728)
    ...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....

  • Yeah, but... (Score:5, Insightful)

    by Schnapple ( 262314 ) <tomkidd@gmail . c om> on Wednesday October 30, 2002 @12:55PM (#4565731) Homepage
    Isn't The Middleware Company the same one that produced this report for SUN Microsystems [sun.com] and concluded that J2EE is the better of the two platforms for a variety of non-performance-related reasons? I think this report is one of the best, most coherent reports on what exactly J2EE and .NET really are and what the differences are.

    So is it that The Middleware Company will just claim that the winner is the one that paid them? Or is it that .NET really is the performance winner whereas J2EE wins most of the other awards?

    And why is it surprising that the performance winner is the one whose entire platform, from the operating system to the SQL server to the framework, is made by a single vendor? Of course it will perform better - they're all in the same building (or complex in this case).

  • Lies, damned lies (Score:3, Interesting)

    by PhysicsScholar ( 617526 ) on Wednesday October 30, 2002 @12:55PM (#4565734) Homepage Journal
    OK, first off, I don't care how many lines of comments or exception-handling routines you take out, the Microsoft solution was still 7 times smaller. If a sub at two different stores costs the same $5.00, I would definitely buy the 7-inch one over the 1-inch version for the same price; essentially, it's better no matter how you cut it (no pun intended).

    Furthermore, if Yahoo moves from C++ to PHP for the majority of their Web applications, I think that's saying something. Perhaps J2EE and .NET are irrelevant at this stage in the game, and a PHP vs. ASP review would be more relevant.
    • Since in MS's eyes, the ASP world should move to ASP.NET, how do you divorce ASP from .NET? You really can't.

      As to the rest of the article, it seems as if only the hopelessly naive or people with an axe to grind will pay much attention to reports like this.

  • Couldn't Resist Though, Eh? (Score:3, Funny)

    by 4of12 ( 97621 ) on Wednesday October 30, 2002 @12:55PM (#4565742) Homepage Journal

    It didn't seem all that exciting, and we sort of ignored the story.

    Maybe we could get a bunch of people to whip up a controversy about a benchmark whitepaper comparing performance of rcp and ftp.

  • Regus Reporting? (Score:3, Interesting)

    by Yankovic ( 97540 ) on Wednesday October 30, 2002 @12:58PM (#4565776)
    Anyone find it particularly hilarious that the Register couldn't even report [theregister.co.uk] the results correctly? Fine that they get anti-MS people to put in quotes, but the facts of the case (namely 14k lines of code for java v. 2k lines of code for .NET) were reported in reverse? Ugh... how these guys have a website is beyond me.

  • Sheesh (Score:5, Insightful)

    by Reality Master 101 ( 179095 ) <.moc.liamg. .ta. .101retsaMytilaeR.> on Wednesday October 30, 2002 @01:02PM (#4565807) Homepage Journal

    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.

    So let me get this straight. A report comes out (that looked pretty fair to my eyes) where .Net kicks the crap out of Java, but that's not interesting. But as soon as someone puts out a (pretty silly IMO) refutation of said report it's suddenly interesting?

    Yeah, yeah, I know -- it's Michael and it's Slashdot. But sheesh, come on.

    Anyway, is anyone really surprised that .Net is going to be much faster than Java? It would be hard to make it slower, and if I were in charge of the .Net project, that would be one of the first issues I would address if I was making a competitor to Java.

  • I have no problem with microsoft's coders.. (Score:5, Insightful)

    by tenchiken ( 22661 ) on Wednesday October 30, 2002 @01:02PM (#4565816)
    It's their business ethic I can't stand. .NET is the most exciting thing in distributed component programming since Objective-C and NeXT. Unlike, Microsoft has enough influnce to acutally make a new programming language part of the vernacular that programmers use.

    I have deployed two different production systems off of .NET, and have been utterly amazed at the API. While C++ has about 50/50 curve (50% of the things are really easy to do, the other 50% suck) and Java raises that to about 70/30, C# and more importantly the .NET framework allow programmers to naturally write good n-tier applications. (In fact, my biggest critique on .NET is that it tends to force people to n-tier when that is not completly appropriate).

    J2EE is a horrific mess in many ways. The abstractions don't map well to real world concerns (for example, a bean represents a row, not a business object, unless your business object is a row, in which case you are probably over exposed to changes in the database), and the API's for SOAP et all are poor (unless you use Glue which rocks beyond anything else I have seen in Java).

    Java's basic trade offs are part of the problem. Remember that Java was created for the purpose of running on embeded systems. This makes very simple tradeoffs (for example, optimizing for size in the bytecode instead of performance) that are not real good for large applications.

    Finally, Java is object oriented. .NET is component oriented. Refliction, delegates, events, emission, cross domain calls and third party language itneroperability are all first class in .NET...

    Now, if Microsoft's business guys would just follow suit.
    • for example, a bean represents a row, not a business object, unless your business object is a row, in which case you are probably over exposed to changes in the database

      I'm assuming that you are referring to Entity EJBs, as a 'bean' is basically any java object with a null constructor (and usually setter and getter methods), and can represent anything you want. But even for Entity EJBs, it's only true if you use CMP (container managed persistence). If you implement BMP (bean managed persistence) you can use them to represent any kind of business entity. We are currently implementing an entity bean that represents data that has been pulled off a mainframe (not an RDBMS in sight), with the EJB/container providing the cacheing/security/pooling etc for us.

  • The important question to me is does each application platform scale with commodity hardware? If so, then the more important question is which takes less time to develop and what is the availability and price of programmers for each platform? Hardware is cheap. Development time is expensive.

    Benchmarks, while to completely useless, are almost completely useless.

    I don't recall anyone EVER claiming that Java's execution speed kicks ass... I don't think execution speed was ever a big selling point for Java.

  • Apples and Oranges (Score:5, Insightful)

    by moogy ( 472637 ) on Wednesday October 30, 2002 @01:04PM (#4565829)

    The original J2EE version of the Petstore application was meant as an EDUCATIONAL example for those new to J2EE. As such, it was not built with performance in mind, but rather was built with the mentality "How can we use every aspect of J2EE to implement this incredibly simple problem." No one in their right mind would use J2EE or EJBs to implement the Petstore app. It would be overkill in the extreme. And even if the J2EE version of the Petstore app was modified for performance, it's unlikely you'll be able to beat something that was built from the ground up with performance issues in mind. I'm sure this was the case with the .NET version.



    If you want a good comparison of a .NET and Java version of the Petstore app, check out JPetstore [ibatis.com] which was built from the ground up with simplicity and performance as high priorities. Hopefully in the upcoming weeks we'll see some good benchmarks using this version instead of the J2EE version.


  • One point about the refuting article is that it talks about the merging of data and business logic layers stretches the idea of object oriented. Although the code be less reusable, merging the two layers is in fact a very intuitive way to piece an application together and doesn't overload a project with excessive classes. As well the GUI will tend to dictate what functions can be performed. If the code is just gonna be used in that one page I don't think code should be anywhere than in that page.

  • performance of programmers (Score:3, Interesting)

    by axxackall ( 579006 ) on Wednesday October 30, 2002 @01:06PM (#4565852) Homepage Journal
    Run-time performance is really a concern for system administrators, integrators and IT managers. The difference in run-time performance should be compensated by faster hardware, which gives a difference in cost of ownership. I expect such difference will be significantly less comparing to the difference in cost of software production, which is in essence a difference in performance of programmers, which in own turn time is very expensive.

    Therefore, it is much better to compare how both technologies help individual programmers as well as their teams to work faster and to produce a code with less errors (debugging time and QA resources). That would be a function of how API is structured, how concerns could be separated, how customizable code can be and will programmers tend to hardcode "business logic" riles.

    Does anyone know such comparison of J2EE and .NET?

  • well duh (Score:4, Insightful)

    by papskier ( 263483 ) on Wednesday October 30, 2002 @01:06PM (#4565856)
    Microsoft wrote the .NET version, while these "experts" wrote the Java version - I stopped right there. Of course if you actually have the people who created the technology in the first place they're going to be able to build a faster app - they know everything inside and out of the technology. It's ridiculous. Show me a comparison between a team of Microsoft employees and a team of Sun employees and I might consider it good enough to be annecdotal at best.

    Besides that, look at the line comparison in code - the .NET version was 11,000 lines and the Java version was about 2600 lines. Clearly what happened here is that the Microsofties decided to be smart about it and write all their functions inline - not pretty but fast. Whereas the Java coders invoked class after class after class - which looks better but all the instantiations and memory allocations of classes are a big performance hit.

    Why not just take an Intel chip architect and tell them to come up with something in byte code, I'll bet it'll knock the crap out of everything else!


    The point is, if you created the technology, of course you're going to be able to make it faster because of your intimate knowledge. Unfortunately, I didn't create .NET or Java, so I guess I'll have to judge them on the merits of their realistics pros/cons.

  • Here are the reasons why this comparsion is BS (Score:5, Insightful)

    by darthaya ( 66687 ) on Wednesday October 30, 2002 @01:07PM (#4565862)
    BS stands for bullshit.

    a little history of pet fight.

    the petstore was originally a demo application written by sun. it was a tutorial tool to demo how to use some new j2ee technologies, some best
    practices and good design patterns, a 101 course for j2ee. Nothing involved to run as a real world applicaiton or optimazed for that.

    then came the MS petstore for .Net. a design clearly aimed at performance and competition, MS declared their petstore is much faster than Sun's. It is a absurd and ridiculous marketing trick only MS could think out. (when they hire poople, they do ask them to think out of box by asking some stupid tricky questions, do they?)

    Since it is a marketing trick targeted to nono technical managers, j2ee camp reacted by their own performance petstore, Oracle has their own version
    running under oracle app server and db. I can not remember exactly the figure of the result, but it is at least 10 times faster than the .net one.

    MS lost this round, they must have thought very hard for a while, now we have this new report.

    The report published by TMC, the company has a web site theServerSide.com which has very high reputation in java community. MS obviously put a big money in the boss's hand and forced the report to be published. Some tricks they used now:

    1. a brand new beta version of .Net VS two outdated version of j2ee app servers.
    2. using Wintel machine for .Net. VS linux for j2ee. (linux version of j2ee usually is the slowest one because other venders always tuned to their own hardware first, then windows, last resource is given to linux, recently IBM
    and Oracle changed their priority i think.)
    3. using extensive cache for .Net VS using the slowest and now abandoned BMP Entity Bean for j2ee. (the new CMP Entity Bean not only faster, but also has very good cache machanism.and directly jdbc perhaps even faster if you only
    care about the speed. )
    4. MS invited to tune their application VS IBM, BEA, SUN have zero idea of this project.
    5. running db and app server in same machine. (J2ee is designed for distributed computing, that is why a high overhead for EJB technology etc)
    6. trying to give a impression that TSS j2ee experts joined this competation, but the fact is none of them involed. so they just fighted with a dummy made by themself.

  • Thought it was illegal. (Score:3, Flamebait)

    by www.sorehands.com ( 142825 ) on Wednesday October 30, 2002 @01:08PM (#4565877) Homepage
    I thought that this type of benchmark was breaching the EULA from Microsoft. But, after reading the report I found it to be legal. Since the benchmarks put .NET into a good light, then it is ok. If the benchmark put .NET in a bad light, then the benchmark is not allowed.

  • Not exciting? (Score:3, Insightful)

    by targo ( 409974 ) <.moc.liamtoh. .ta. .t_ograt.> on Wednesday October 30, 2002 @01:11PM (#4565915) Homepage
    You would have been jumping up and down with excitement, had the results been the other way around. Let's try to have at least an illusion of objectivity, OK?

  • Uhhh, why is it suddenly newsworthy? (Score:3, Insightful)

    by coupland ( 160334 ) <<moc.liamtoh> <ta> <esahcd>> on Wednesday October 30, 2002 @01:17PM (#4565974) Journal
    Soooo..... When .NET beats the pants off J2EE it's not newsworthy, but when someone questions the results it is? Surely if one is worthy of posting on /. they both should be...

  • Error rates (Score:3, Interesting)

    by Animats ( 122034 ) on Wednesday October 30, 2002 @01:20PM (#4566014) Homepage
    What went wrong with "J2EE App Server B"? After two hours, it choked completely. But they don't say why. Even "J2EE App Server A" got 40 errors. The .NET servers supposedly completed the 24 hour load test without errors.

    Incidentally, all this stuff was run on Windows 2000. Somebody should try it on Linux.

  • I'm just waiting. (Score:3, Interesting)

    by glh ( 14273 ) on Wednesday October 30, 2002 @01:22PM (#4566030) Homepage Journal
    There will probably be another J2EE implementation that can "beat" the .NET benchmark. However, I think there is some degree of truth to this particular one. At our .NET User Group Meeting [nwnug.com] last night, we had someone from Microsoft actually talking about this benchmark. He didn't go into much detail on the J2EE side, but said that the MiddleWare company spent 10 weeks trying to get the J2EE implementation tweaked. So either these consultants are really incompetent on the Java platform, or there really is a significant performance difference.

    It's even more convincing in reading the article posted in the link (the "review" that is). Basically it was bringing up how the lines of code count was not correct because J2EE could have done a better job. Bah, that's a silly argument. LOC can't just be brushed off because it really does have something to do with the cost. More lines of code isn't just for "lazy programmers", it's also a factor when you have to think about MAINTAINING that code.

    However, I do buy the argument about not using the "latest and greatest" J2EE. So, I get back to my original point.. I'm just waiting for the next benchmark.

    So since the author complains about the PetStore app as being such a bad design, how about coming up with a new one and then comparing those? It seems to me like, no matter what, the author of the article doesn't believe .NET could *ever* be faster/better/etc. than J2EE. So really, it's a religious thing and I don't think any amount of proof will convince him. And I'm sure there are certainly others out there thinking that way. Of course the other camp also believes .NET is "all that".

  • was MS involved? (Score:4, Informative)

    by loconet ( 415875 ) on Wednesday October 30, 2002 @01:22PM (#4566031) Homepage

    From their FAQ [middleware-company.com] about the benchmark..

    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.

  • They used BMP (Score:5, Insightful)

    by vlad_petric ( 94134 ) on Wednesday October 30, 2002 @01:22PM (#4566033) Homepage
    ... and claim it's gotten them better performance ? With bean-managed persistence the developer writes the SQL code for accessing the beans; this gives a lot of flexibility, but prevents the container from doing a lot of optimizations.

    Anyway, such a comparison is flawed from the start. Bench suites should be developed by independent 3rd parties, or consortiums like SPEC and NOT by vendors.

    I actually don't find the results surprising. Microsoft's pet store is heavily optimized for an app server/SQL server; the standard EJB pet store should work with minimal tweaking on any EJB-compliant app server / SQL server pair.

    The Raven

  • Did no one read the other article linked to? (Score:5, Informative)

    by j3110 ( 193209 ) <samterrell @ g m a i l.com> on Wednesday October 30, 2002 @02:20PM (#4566650) Homepage
    I've been using J2EE now for a while, and they made some hideous performance mistakes. The #1 mistake they made was BMP. BMP, for those of you who don't know, is an object persistance model where each object manages it's own storage. It's pretty obvious that for N rows of a database that map to N objects, you will need N SQL statements. That's just wrong and bad. Not only is it the slowest way to access the database, but it requires 10x the amount of code to work with. The other two (common) choices are CMP and JDBC in session beans (others are JDO and other ADO-ish Java API's that wrap JDBC). CMP would require 1 SQL statement to retrieve N rows, and requires no SQL be written, works on all RDBMS's, and you only have to write a skeleton object. It's about a magnitude of 3 faster than CMP. Directly connecting from the Session beans(pretty much a CORPBA object) will make you write your own SQL, but will increase performance yet further(since you can use stored procedures or just do mass updates and still maintain database independance).

    The next thing they did is exclude JBoss, one of the most popular J2EE servers. It's open source, and easy to use. One can only conclude the intentionally left it out because .Net could never hold up to best price/perf. against free. JBoss may not be a speed deamon(it's not slow at all though), but if you disable debugging(on by default), use IBM JDK 1.3.0 and MySQL with innoDB, it will easily win price/performance.

    After reading that TMC had taken money from MS, the only conclusion that I could come up with is that it was rigged. No real J2EE expert would ever make those mistakes. Even free E-Books on TSS will tell you not to make mistakes like that.

    Basically, this really hurts the Java community to see TMC take stabs at J2EE after all it's put into it. Either that or we are to conclude that TMC is unfit for the J2EE educational services they offer. Either way, they may have helped .Net get a foothold, but they are loosing theirs fast.

    Anyone that doesn't know that much about J2EE or doesn't take a look at the code will think this is like the florida recount fiasco, but it really is a legitamit claim that this version of the petstore was really written by A) a monkey, or B) a MS fundee.

  • The Java PetStore was never a benchmark (Score:4, Interesting)

    by carlfish ( 7229 ) <cmiller@pastiche.org> on Wednesday October 30, 2002 @03:49PM (#4567703) Homepage Journal

    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 [ibatis.com] 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

Slashdot Top Deals

"The following is not for the weak of heart or Fundamentalists." -- Dave Barry

Close