Slashdot Mirror


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.

7 of 480 comments (clear)

  1. Performance isn't most important by Faggot · · Score: 4, Interesting

    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.

    1. Re:Performance isn't most important by SirSlud · · Score: 4, Interesting

      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.

      --
      "Old man yells at systemd"
    2. Re:Performance isn't most important by j3110 · · Score: 4, Interesting

      Which brings another point to the table actually. J2EE is a spec, not a product. It makes no sence to say that J2EE is slow. There are no implementations of J2EE using Java's new asyncronous IO (NIO) libraries. Someone implemnted a webserver using NIO and it blew away Apache performance as well at raw serving. Of course it was so fast that it had to be run on a loopback interface so it doesn't matter at all. The big performance hit this takes is to the database. The DBMS in this Java version requires an SQL statement to return all the keys, and then one to retrieve each line from the DB. It doesn't have to be that way, it just is because they are dumb appearantly :) The SQL server has to parse the SQL for every single statement. That's not exactly CPU friendly either :)

      --
      Karma Clown
  2. Benchmarks for tasks with N-number of variables... by Art+Popp · · Score: 4, Interesting

    ...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....

  3. You've got it reversed. by nobodyman · · Score: 5, Interesting


    Did you intentionally reverse the figures? The .NET version was 2000 lines of code, and the Java version was 14,000 lines of code

    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 .Net version used stored procedures instead of dynamic SQL statements (Sun advises dynamic sql for easier portability and because they are idiots). This time, they addressed the Java camps' gripes and J2EE still lost!

    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.

  4. Re:Are there any reviews that show the opposite? by the+eric+conspiracy · · Score: 4, Interesting

    Oracle did a study showing the reverse with their app server and database.

    http://otn.oracle.com/tech/java/oc4j/pdf/9ias_ne t_ bench.pdf

    In Oracle's study, they achieved results that were as much as 22x faster than .Net

  5. The Java PetStore was never a benchmark by carlfish · · Score: 4, Interesting

    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.