What Influences the Performance of Application Servers?

Home

News: What Influences the Performance of Application Servers?

  1. Despite the number of benchmarks available, no single benchmark can be used to predict an application server's performance, which depends on a variety of factors including features, access paths in and out of the server, the type of application hosted, and deployment topology. A new article on java.sun.com explores these factors.

    Read What Influences the Performance of Application Servers? (first published Nov 15 from devleoper.iplanet.com).

    Threaded Messages (57)

  2. Am I missing something ?

    That article appears just to be some sketches of
    various high-level deployment models at an
    executive summary technical level !
  3. I am a sw consultant for large companies where a see every kind
    of j2ee-based application.

    No one of these is up to a real speed.

    Tens of developers (permies) are brought in to barf out
    tons of rad automatized code losing the grip onto every single
    inch of meaning into it.

    Oracle with JDBC, connections, EJB JMS and even jsp and servlets (the easy ones) turn into unmantainable tangled behemots of nonsense.

    Then Bea or IBM are called in and more and more money is wasted
    without an answer.

    And you can't tell clients that "Application Servers" suck since they are responsible of investing tons of euro$ into EJB, this great Programming Object Orineted Paradigm (POOP).

    On the other hand, my systems, developed with C++, STL and CORBA (when not XML-RPC) work well from several years, without asking for any maintenance, responsive and shiny, open source and open standards (ISO,ECMA etc).


    ciao,

    Lungo detto il Maltese
    lungomaltese@yahoo.com
  4. Hi Frank,

    Thank you for telling the obvious truth. Java was unfortunately from the early beginning in the hands of a combination of impractical theorists and young, gifted programmers but with no real world experience of being burned. Practically every day there coming a benchmark bashing Java but nothing can sway this die-hard J2EE/EJB zealots, all is bought by Microsoft even their own forum!

    Also I have been browsing a lot the last weeks trying to discover at least one(1) large scale J2EE site totally in vain.

    Regards
    Rolf Tollerud
  5. I'm disappointed to see comments like these. There doesn't seem to be any explanation of /why/ the authors believe 'Java' is 'crap'.

    A Java Virtual Machine is an abstraction layer on top of the many others already present in your environment: the virtual memory subsystem of your operating system, the interface your CPU exports and in the case of some processors even the instruction set your operating system is written in. All of these layers increase flexibility at the expense of raw performance, yet we don't complain about the others: few wish to write directly in machine code.

    You can't blame 'Java' for the failings of developers and development teams. You can write a 'crap' piece of software in Java, the same as you can in C++, COBOL, VB, or any number of other languages and environments.

    Paul
  6. Hi Paul,

    > I'm disappointed to see comments like these. There doesn't >seem to be any explanation of /why/ the authors believe >'Java' is 'crap'.

    I'm disappointed to see that java-based technologies didn't
    became viable since the start of the java revolution

    I stated exactly because java is "crap": it produces slow, unmanteinable applications that look like toys written in some Logo or other silly languages.

    Project like

    Corel Office For Java,
    Navigator in Java
    Staroffice for Java were announced and helped
    bringing companies to failures.

    Today i use TogetherJ UML TCC, since it's the best tool
    for writing C++ using a brain, but i curse every time and
    forever for the burden that it means for my machine.

    At some points, even with 512Mb and 2GHz PIV i stop use it because the complexity of the model tears it down.



    >A Java Virtual Machine is an abstraction layer on top of the >many others already present in your environment: the virtual >memory subsystem of your operating system, the interface >your CPU exports and in the case of some processors even the >instruction set your operating system is written in.

    Should I say that i know?
    No new stuff (Smalltalk, UCSD Pascal).

    >All of these layers increase flexibility at the expense of >raw performance, yet we don't complain about the others: few >wish to write directly in machine code.

    Few know how to code in ways that are more efficient.
    Coders are rent in India or Burkina Faso and replaced
    at speed of light when four pills of rice are considered too much.

    And even in "civilized" or more "advanced" countries (EU,UK,USA): how many persons say "i'm a java programmer" when they hardly know visual basic?
    How many of them are put onto important projects by Accenture, IBM, Oracle, Deloitte or other Enron-like companies??

    I doubt they could even spell CORBA exactly, not to mention put their hands onto a STL based C++ program.


    >You can't blame 'Java' for the failings of developers and >development teams. You can write a 'crap' piece of software >in Java, the same as you can in C++, COBOL, VB, or any >number of other languages and environments.

    Agree.
    Only that Java-only programmers are crappier than others,
    because the system itself tells them not to care about memory, performance etc.

    Another thread another day if we want to talk about
    WAS, WL etc, and the "flexibility" of EJB...


    >Paul

    Ciao,
    Frank Grimes
  7. That is something interesting to hear.
    We are building a large J2EE web app using Dynamo ATG and we ran into a number of performance issues.
    We discovered that lot of our issues are due to J2EE paradigms (CMP Entities, RMI implementation), App Server and some amount of crappy code.
    After months of tuning with some improvements, we are at point to say we can do as much only in the code and lot of it is beyond us in the App Servers, JAVA VM .

    Interstingly we were thinking of WL (being popular) must be lot better and there was even proposal to build POC and port our application sometime...

    Well, looks like all are in same boat and they are good for building some small prototypes only....
  8. "We are building a large J2EE web app using Dynamo ATG and we ran into a number of performance issues.
    We discovered that lot of our issues are due to J2EE paradigms (CMP Entities, RMI implementation), App Server and some amount of crappy code."

    It turns out that a major problem with J2EE is that it makes it easy to wirte distributed programs. The problem is that it is hard to design distributed programs. Blaiming the infrastructure is an easy out, but it doesn't fly. There are too many examples of well done systems.
  9. I consider J2EE (and particularly EJBs, CMP and the like) INFRASTRUCTURE. All the same for the Application Servers. Those are getting commodities. And it's no wonder IMHO that users want less and less to pay for them, hence the incredible success of JBoss vs commercial app-server vendors (a fact that couldn't be stressed too much).

    What becomes more and more obvious on the other hand is that RAD tools ARE needed indeed (a few consulting companies have reported on this recently on this very site) so that some kind of development "platform" can emerge out of using the J2EE infrastructure.

    I don't like abstraction layers either I must say, particularly when those are the consequence of adopting some vendor's arcane proprietary tools.

    Sun has shown everybody the way to go with J2EE, but to a certain extent only. They should've done a little bit more. And not surprisingly, .NET did those little steps further, by leveraging an Integrated Development Environment along with the infrastructure.

    If we as Java developers want to leverage the full power of J2EE to enterprises, we must find a way to let managers have a grasp on it.

    My two cents: I'm using rules with J2EE and it makes it all very fun. The logic becomes clearly understandable for everyone and J2EE really shines at what it does best: caching, persisting, distributed transactions,...

    Candide
  10. Candide,

    <Q>..hence the incredible success of JBoss</Q>

    I went to the JBoss site and looked for references. I found four (4) links, none of which says they are using EJB. So can you please direct me to some large scale sites that are using JBoss? I am curious but not difficult to please, one(1) will be enough.

    Thank you

    Regards
    Rolf Tollerud
  11. A bit of "deconstruction" seems needed here (see "http://www.info.ucl.ac.be/people/PVR/decon.html" for the process of deconstruction, but I'm not sure that you really have to bother ;-)

    <cite>I went to the JBoss site and looked for references. I found four (4) links, none of which says they are using EJB. So can you please direct me to some large scale sites that are using JBoss? I am curious but not difficult to please, one(1) will be enough.</cite>

    I will begin to state one simple truth: JBoss holds a bigger market share than WL (I think the figure is something around 30%- WL and 40%+ JBoss)

    So you looked for "references": means that somehow JBoss could maybe not be used at all, huh ??? OK it has 40+ market share but nobody's using it ! OK, well it seems that "4" people are using it. Great, but they don't use EJB's. But are you saying then that those using WL *do* use EJB's ???

    Could you please make your point a bit clearer ?

    Anyway, Nik is very wise to point out that EJBs were first introduced as a distribution-enabling technology and I would add that people were very wrong when they compared them with more lightweight technologies like JDO, saying that that's what they should've been in the first place. I think the distribution features of J2EE are great, but completely mis-used. The introduction of local interfaces was refreshing in this respect, and I personaly think that maybe Sun should've first made EJB's local and then distributable. That should've made people with simple requirements more comfortable for using the technology.

    Cheers,

    Candide
  12. It turns out that a major problem with J2EE is that it

    >> makes it easy to wirte distributed programs. The problem is
    >> that it is hard to design distributed programs.

    Agreed 100%.

    I have to say that many "J2EE" critics dont have experience building distributed systems - hence they dont understand the source of the complexity (they blame J2EE instead)
    (Many think that just because it is a web app, it is a distributed system)

    Moreover, many that have failed in J2EE projects have probably failed because they dont undestand the design issues of distributed systems.
    I have seen the same failures in C++ CORBA projects. Sadly J2EE cant fire poor programmers.

    I find it very interesting that many of the very vocal critics of EJB, for instance, havent had any real experience with it; "I have used Java for period, but only for web projects with servlets"

    Anyone who says "Application Servers suck ... On the other hand, my systems, developed with C++, STL and CORBA (when not XML-RPC) work well " obviously hasnt really done any real J2EE programming. Moreover, they probably havent had a good hard look at the amount of infrastructure code they have to write for C++ and CORBA - or the problems in maintaining such systems.
    With experience in C++ CORBA, I can catagorically say that it is a significant waste of time developing new systems in CORBA or C++ unless there is no other way (and almost always, there is another way).

    Those looking for "at least one(1) large scale J2EE site" might be dissapointed to discover that not all applications are web sites and not all web applications are on the internet.
    Basically, in the banking and financial sector where I work, most applications are internal systems, settlement, trading, pricing, risk/position etc etc.
    There are *many* large-scale applications that have been built and are being built on J2EE.
    This is not to say that it is not possible with other technology. However, for some time now, for many peers I talk to, J2EE is the default choice for large-scale systems.
    Also, more importantly, their justufication of their opinion does not come from something they heard or something they read in a magazine - it comes from experience.

    -Nick
  13. "I have to say that many "J2EE" critics dont have experience building distributed systems - hence they dont understand the source of the complexity (they blame J2EE instead)"
    From the experience of CORBA based didtributed systems (on C++) here are my thoughts
    C++/CORBA:The frameworks you had to build took long to build and are not ensured to be bug free/scalable. J2EE:You just have to wory about building your applications and app server implementations are supposed to have been more mature than your custom code.
    My question: Are app server implementations really good? My experience has been -Ve
    C++/CORBA:The custom framework would get outdated soon and lot of investment go into mainitaining it. J2EE:Somebody else is defining newer standards and implementing/mainitaing it.
    My question: When newer standards come up and App Servers implement it, how easy is it to upgrade applications to run on newer standards. My experience has been -Ve. C++/CORBA: You cannot switch to new framework if you dont like your own framework. J2EE: You can easily change your app servers. My Question: Are J2EE applications really portable across app servers?
    C++/CORBA:It is hard to find disciplined programmers who understand distributed systems well and hence time to build new applications or cost of building new applications is very high. J2EE: Programmers are not expected to be as knowldgeable and you can build large systems fairly quickly at a lower cost
    My Question: If the programmers do not have good knowledge of distributesd systems and protocols the systems built are not scalable. and the J2EE systems built have to be usually reengineered and maintained over longer periods of time thus negating any benefits that you had got building it quickly anyway.

    Well after all this, I still think paradigm shift has hapened and J2EE is almost the default choice for large scale distributeed systems,whether I like it or not.
  14. Panduranga,

    You mean sites like Yahoo Finance, The National Bank of Costa Rica who emigrate their total system of 3 mill rows of code to .NET or Merrill Lynch with 75 million transactions per day at 25 million users (that’s 21,000 transactions per second)?

    Regards
    Rolf Tollerud
  15. Panduranga, good questions/points:


    >> My question: Are app server implementations really good?
    >> My experience has been -Ve

    I am not sure what appserver you have used. Most of the appserver implementations I have used have been easy to set up, easy to deploy to, feature-rich, up to date and very reliable.
    My experience with Orbix C++ (Sol & NT) have been less than favourable.
    a) Its C++ - negatives are too many to list here.
    b) You have to write loads of infrastructure code (object lifecycle management (evictor anyone?), persistance management, security, transaction management). Its a right pain.

    >> My question: When newer standards come up and App Servers
    >> implement it, how easy is it to upgrade applications to run
    >> on newer standards. My experience has been -Ve.

    What has been your particular experience here?
    Migrating from EJB1.1 to EJB2.0 would be a cinch.
    Migrating between servlet specs I have less experience of - but I cant think of anything major that would make this difficult...

    >> My Question: Are J2EE applications really portable across
    >> app servers?

    I have seen an application with 3 man-years worth of code developed on Weblogic, deployed on Websphere in 2 weeks (for some benchmark testing). I dont think that is too bad.
    Largely it depends on your application - and your target container. If the new target lags the specs by 12 months or more, it doesnt make it easy, I agree.

    >> My Question: If the programmers do not have good knowledge
    >> of distributesd systems ...

    I dont think that even with J2EE, you can successfully build enterprise applications when no-one on the team has knowledge of distributed systems. However, I think the odds are much better than with C++ or with CORBA.

    I think the main difference between J2EE and its predecessors is the fact that with J2EE not *everyone* on the team needs to be experienced with the technology. You can get by with one or two experienced mentors.
    With J2EE there are far fewer *implementation* issues. The design issues will always be there, regardless of technology.

    I have personal experience with a J2EE team, almost all of whom were new to Java (let alone J2EE!). They have produced an application using Struts, JMS, SOAP, EJB, CMP2 (using CMR) and it runs reasonably reliably and didnt take an excessive amount of time to build.
    There was one experienced guy on the team for the first 3 months or so - and I have been casually involved throughout.

    While its true to say that mistakes have been made due to their lack of experience, they have usually discovered them very quickly. When they havent been able to solve the problem themselves, it has been very easy for an outside (experienced) person to step in and spot the problem and help them out very quickly. I have never had the same experience with CORBA C++ - usually the possible causes of a problem are legion.

    -Nick
  16. Nick,
    I agree to most of what you say.
    I liked the J2EE when I switched to it in the last 2 projects from C++.
    -- Development times are reduced about 3-4 times from the earlier days.
    -- Programmer skills are not required to be as rigorous in C++/CORBA envs.

    But here is when I started to question J2EE or Application Servers to be precise.
    The application we designed ran into lot of performance problems under load. This large application was developed in less than 6 months and had good number of experienced J2EE designers.
    I believe the application is fairly well designed. Most J2EE good prcatice and architectural patterns are used. (Session Facades, Value Objects, Proxy patterns, Home factories, Page caching for frequently used information).
    But the application had problems in scaling to 4000 Concurrent Users at 50 TPS on SunFire 4800 servers.
  17. But the application had problems in scaling to 4000

    >> Concurrent Users at 50 TPS on SunFire 4800 servers.

    Have you profiled your app? What did the results indicate was the bottleneck?
    (ie Why is it not scaling? CPU? Network? Database?)

    Out of interest, what appserver were you using?
    What JVM?


    -Nick
  18. We have done considerable amount of tuning the code.
    Initial problems were with CMP Entity Beans and the SQLs fired from the CMP engine were not optimal.
    From our tuning and profiling our application is very memory intensive. We are consuming 500 MB of memory for 100-150 Web requests. We have given maximum memory to the heap (2.5 GB) and have tuned the generational sizes such that the Full GCs are reduced.
    We still do see some server pauses during minor GCs (not too many, but 20 out of 150 odd GCs in about 8 peak hours) that take 10-15 seconds some times. Some of these times server seems to be hanging and that makes business users very nervous.
    We are on ATG Dynamo 5.6.1 and JDK 1.3.1_04 Hotspot Client VM
  19. In other word, yet another Sun - "Big App Server" + Oracle project down the drain. SOB!

    What a appropriate acronym.

    Regards
    Rolf Tollerud
  20. Rolf,
    Thanks for your invaluable contribution.

    Care to answer some of the questions I have asked you on this thread? It seems that with your depth of experience in J2EE and EJB in particular, and also given your unique understanding of J2EE, that you have some valuable contribution.

    -Nick
  21. Hi Nick,

    I carefully read through all your posts and could not find any question except "What does bloated mean?"

    What you are saying is more that you do not have had any problem with using Applications servers and J2EE/EJB. But I suspect that your background and experience is something similar to Ray Harrison, and if that is true, if this level of experience is necessary to succeed, it is rather useless for the big community.

    "What does bloated mean?"

    My distrust of "big" development environments goes back longer that J2EE. You know as well as I that there exist no such thing as a "bug free". If you introduce a layer with hundreds of thousands of rows of code between yourself and your customer you take a big risk. That goes for the old PowerBuilder, for ATG Dynamo, and for the big EJB servers. Just wait until you get the dreaded "thread lock" in some internal place over which you have absolutely no control.

    Regards
    Rolf Tollerud

    P.S And btw theserverside.com site did go down this night too..
  22. What you are saying is more that you do not have had any

    >> problem with using Applications servers and J2EE/EJB. But I
    >> suspect that your background and experience is something
    >> similar to Ray Harrison, and if that is true, if this level
    >> of experience is necessary to succeed, it is rather useless
    >> for the big community.

    If you read my posts you will notice that I have seen teams with virtually no J2EE experience succeed. Just the basic competancy required for building any enterprise system and, in some cases, some mentoring.

    The issue I have with your arguments is credibility. You seem to be a very vocal EJB and J2EE critic - yet you have little experience with the technology and, whats more, you display little willingness to actually understand the technology ("I do not want to waist time learning something which I regard as a piece of shit").

    -Nick
  23. Nick,

    <Q>you display little willingness to actually understand the technology</Q>

    Even if I had not downloaded different EJB containers like Weblogic, Websphere, JBoss and played with them, not read the "101 damnations of EJB" or "is J2EE harmful to Java" from Jakarta, nor carefully studied Robert Session "A critical look at EJB", not read hundreds of negative comments about EJBs here in the J2EE forum, been unable to find a single large scale J2EE/EJB application , been horrified when I read "the new EJB spec have a new ORDER BY clause", never have seen a successful implementation of J2EE, observed that implementations is really impossible without tools that generate tons of code and deployment descriptions, observed that J2EE followers looks upon someone who says " Organize inter-service transfers according to use cases from known domain objects into a coarse-grained Composite" as a great guru, and observed that this very site goes down practically every night..

    Even if none of this was true, even if all was completely new to me, I have to say that only the discussion between you and Panduranga would have been enough to make me steer clear of J2EE at any cost.

    Regards
    Rolf Tollerud
  24. "Even if none of this was true, even if all was completely new to me, I have to say that only the discussion between you and Panduranga would have been enough to make me steer clear of J2EE at any cost. "

    Are you a system developer???

    I can´t see what´s so astounding in their discussion... Just normal analysis that should be make when you´re developing any real distributed system. Maybe when you´re using other tech(not j2ee) you would use another names, and have other issues, but the issues ARE ALWAYS there...

    That´s our job, remember?

    Andre Augusto
  25. Andre,

    J2EE is as dead as Lambada, a fad gone. And like the guys in New Your that hosted a farewell party to the Lambada to get rid of it I gladly host a J2EE farewell party myself!

    I have no doubt whatsoever that the Jakarta teams - unmatched for their professionalism - will come up with something better.

    Regards
    Rolf Tollerud
  26. salve,

    i pretty much agree that ejb part of j2ee is not *very kool* because it was supposed to ease development of middletier well i have not seen any of that ease - i compare it to recent .net that actually does make it easy as far as i can see.

    but then - making it easy when one owns the platform and sets ones own standard is not surprising, is it.

    all i can say if anyone finds ejb sucks, just switch, do something else, but bashing does not change fact does it...

    personaslly i find ejb an uphill struggle. comaptiblity between servers, complex deployment, getting persistance layer and state sorted, async messaging etc...

    ejb was not ment to ease design - sure how could it. design is not part of the language or thecnology...

    it might actually be better for many distributed systems to keep c++ and tuxedo or eqv for middleware and keep jusing jolt like connectors. that was complex enough to keep inexperienced ppl away both from design and from coding. with todays bandwith catching up - 'fat' swing clients written in java delivered by web start might get a second chance (happend already in my field). then java could stay on the presentation tier, merge with the web server/servlet/jsp tier.

    anyway...i make my living as a systems integrator for ecrm. two versions - one ejb, one com (.net on the way). both live happily side by side. customers choose the platform they like. so rolf...if no one else can give you a live example of higly successful ejb implemenation - i can.

    ciao,
    henrik
  27. EJB101 damnations??

    >bad-managers.com. go have a look...

    I've read it. It's pretty clear that the writers don't have a clue. For example, they are asking for property change events in an EJB. There's nothing like distributed events to really slow things down.
  28. It is crystal clear that you make your decisions based on what you read in a magazine or web site, rather than through any sensible means.

    If you are to continue this trend, I suggest that you read articles by people who actually know what they are talking about. (Roger Sessions??? You have got to be kidding. EJB101 damnations??)
    I highly recommend O'Reilly books for a good start (Richard Monson Haefels EJB book is great for beginners).

    >> been unable to find a single large scale J2EE/EJB application
    Are you unable to understand the response I have posted to this clearly silly comment?

    >> and observed that this very site goes down practically
    >> every night
    Have you even bothered to email Floyd to find out why? By what deductive process do you arrive at "J2EE" as the reason for this? Is this your normal approach to problem solving?

    >> I have to say that only the discussion between you and
    >> Panduranga would have been enough to make me steer clear of
    >> J2EE at any cost
    If this worries you, perhaps you should avoid software engineering in general.

    I wish you the very best of luck with the technology you choose.

    -Nick
  29. It is crystal clear that you make your decisions based on >what you read in a magazine or web site

    i disagree. not crystal to me even though i'm not totally in agreement.

    >Roger Sessions??? You have got to be kidding.
    rogers opinions is highly respected by some, and for one he is alot more amusing to read than haefel. more later...
    i'm working on the ejb/com version of a crm system roger used as example of a bright architecture in the book battle of middletier. at the time the ejb version was not real. roger questioned its success. it's been out for a while now and it is and it's a great version. scales and performs very well.

    >EJB101 damnations??
    bad-managers.com. go have a look...

    >Richard Monson Haefels EJB book is great for beginners
    have read all versions of the book. becomes heavier and heavier and finally your eyelids feel like lead... *S* seriously..it is a good book, not doubt. awarded rightly. but reading latest version (observe the increasing size), one must take a step back and ask oneself...is this a path i want to take... there is not much/nothing about it that makes ejb middlware development easy. a highly complex subject for beginners. compare that reading for a beginner as you say, to reading up on doing some c# distributed com+ component under mts... you can not see the ejb for all the interfaces...j2ee idiom #21.

    cheers,
    henrik
  30. ">Roger Sessions??? You have got to be kidding.
    rogers opinions is highly respected by some, and for one he is alot more amusing to read than haefel."

    Sessions is well-known for being an advocate of .net, and anti-J2EE. That would be OK with me if he didn't claim to be an unbiased advisor. He is highly respected only amongst the people that find his pro MS views beneficial (like MS, MS partners, executives who need help justifying .net decisions etc.) I agree that he is an amusing writer but I hope that you do not believe that his EJB opinions are either unbiased or based on any significant experience with the technology.
  31. rogers opinions is highly respected by some


    No-one I know. I find it amusing anyone listens to him - in fact the only people I know that quote him are Anti-J2EE, Microsoft proponents. In anything of his on Java that I have read, he shows little understanding of J2EE or Java at all. His "critique" of JDO was a classic example.

    >> bad-managers.com. go have a look...

    I know what it is. I just question whether they know what they are talking about. The validity of the points they make have been debated long ago on this site. Building a web app is not building a distributed system. There are many web applications that dont have the problems that EJB solves - thats not a problem of EJB.

    >> there is not much/nothing about it that makes ejb middlware
    >> development easy. a highly complex subject for beginners

    Our beginners havent had too much trouble with it.

    While perhaps a little harsh; I believe that if they cant pick up and read RMH's book and understand EJB then perhaps they are not the right people for building server-side systems (its natural that not everyone is).

    >> you can not see the ejb for all the interfaces
    All 2 of them?
    Do you think it is better to code to an implementation?

    -Nick
  32. Hi Nick,

    <Q>It is crystal clear that you make your decisions based on what you read in a magazine or web site, rather than through any sensible means</Q>

    Life is short, you can not do everything. If you read day and night, without eating or sleeping through your whole life, you just will be able to finish the Sumerian cuneiform volumes that are in the possession of British Museum.

    But rather to criticize I will try to show a path onward.

    First allow me to digress a little. For about 20 years ago it was the age of the big really expensive Synthesizers. And among them the was the Synclavier - the best, the most expensive,the state of the art. Not to have been surpassed to this day.

    Still, very few use Synclavier today or any other synth in the $100.000 class. The reason? They were outcompetited by small black boxes for about $330 - $500 each. People put together their systems by combining a number of these black boxes for a price that is only a fraction of the cost of the big systems. The big systems could never keep up with all new technique(=could not keep up with the times, does it ring a bell?), the small boxes was faster. Very fierce competition among the different vendors is all to the good for the customer.

    If we return to the Java world, what is needed is only that Jakarta or somebody else produces a "black box" EJB Container, which can be added to Tomcat, Jetty or any other servlet container to produce TP functionality. Then we have a true "black box" system similar to what they have in music business. Jakarta already has a large number of these black boxes and more coming every day.

    Regards
    Rolf Tollerud
  33. Rolf,

    Your screed is, at most, a betrayal of your own misconceptions and beliefs. Nothing more. Just a lot of hot air. Now I will sit back and await your blast, however subtle or not.
  34. In addition:

    >> If you introduce a layer with hundreds of thousands of rows
    >> of code between yourself and your customer you take a big
    >> risk.

    And writing all that infrastructure code yourself is risk free???

    I know who my money would be on when it comes to writing infrastructure code - and its not the developers with business domain knowledge. I prefer to leave that code to people whose business domain is writing infrastructure code. I.e. middleware/appserver vendors.

    -Nick
  35. Nick,

    And I prefer developers that have experience of the business problem at hand.

    "It is not much use when the tools that are supposed to help you with the problem are more complicated that the problem that are to be solved".


    Regards
    Rolf Tollerud
  36. What version of CMP are you using?

    Where is the memory allocation occuring?

    Have you tried to reduce the amount of object creation?

    Value objects are a common culprit (esp in CMP1.1). The class requesting a VO should pass in one to be populated (thereby it can safely cache the VO, saving on GC)

    Have you also tried the JDK1.4.1 Server VM on Solaris?
    We have tried the 64bit JVM with good results.
    As of 1.4.1 we have asynch GC (therefore no more Pauses :-) ).


    -Nick
  37. What version of CMP are you using?

    We are using hybrid of cmp 1.1 and cmp 2 as ATG Dynamo supports CMP2 kind of features through properitary XML mappings.

    >>> Where is the memory allocation occuring?
    Few top candidates are
    -- XML marshalling/unmarshalling. The application uses XML to talk to legacy systems through a message broker.
    -- DB Calls (Oracle JDBC driver).
    -- Object Serialization and Deserialization. Strangely the business tier calls from web tier is not the cause of all serializations and deserializations (as we find it from profiling tools) and it lies somewhere else.

    >> Value objects are a common culprit (esp in CMP1.1). The >> class requesting a VO should pass in one to be
    >> populated (thereby it can safely cache the VO, saving >> on GC)
    We do not use this pattern. We use conventional gets out of the Entity Beans. I would like understand a little more on how this would benefit.

    >> Have you also tried the JDK1.4.1 Server VM on Solaris?
    >> We have tried the 64bit JVM with good results.
    >> As of 1.4.1 we have asynch GC (therefore no more
    >> Pauses :-) ).
    Well, I wish we could. But server stability is an issue and running app servers on any JVM versions other than the ones that are certified by the vendor are unsupported :-(

    From what I hear none of the app server vendors have really certified 1.4.1 as of yet.
  38. Perf tuning[ Go to top ]

    -- XML marshalling/unmarshalling

    Hmm, yes I have seen that too.
    You might need to do some custom serialisation to reduce object allocation.
    Which SOAP implementation are you using?
    You may want to split some of the legacy access off so that you can cluster it seperately.

    >> -- DB Calls (Oracle JDBC driver).
    From the resultsets?
    Is your CMP engine caching where it can? Can you use optimistic locking for some access (does ATG support that?)

    >> -- Object Serialization and Deserialization.
    Are you in a clustered environment?
    Check that it is not session replication (http session or stateful EJB). Are you sure its not your entity bean access? (ie is ATG optimising out the remote calls?)

    >> We use conventional gets out of the Entity Beans. I would
    >> like understand a little more on how this would benefit

    Does the ATG container support Local interfaces or optimise out remote calls? If not, calling individual get/sets on entity beans is rather costly.

    Does the ATG container hit the database for every get/set - or only at the beginning and end of TX?

    Typically, with CMP1.1, you would get a DataTransferObject to minimise the calls through the remoting layer. Even with CMP2.0, the DTO (or View Object as I like to call it) is built by some sort of external factory (rather than by the entity - better that the entities are oblivious of the views that use them).

    The simplest implementation is to create a new one each time you call a getXXX method. However, when it comes to optimisation, it helps if you can cache your view objects so that they are only created once (you just pass the old one in and the factory populates it with the new data). This saves a lot on the GC. It is important that the caller passes their old one in rather than the factory caching them (otherwise you end up with all sorts of concurrency issues).

    >> Well, I wish we could. But server stability is an issue and
    >> running app servers on any JVM versions other than the ones
    >> that are certified by the vendor are unsupported :-(

    Understood. Still, you should experiment to see if a different JVM helps. I know of people who have spent considerable effort re-working code to reduce object creation - and yet they got less of a perf boost than they did through an improved GC by upgrading JVM's.


    Getting back to your problem, is it actually CPU-bound. Is it just the GC that is throttling perf?

    >> From what I hear none of the app server vendors have
    >> really certified 1.4.1 as of yet.

    I think you are right. However, I know that some vendors have released ECPerf results on JDK1.4 ...
    I have run Weblogic on JDk 1.4.1 with no probs.

    -Nick
  39. Perf tuning[ Go to top ]

    -- XML marshalling/unmarshalling

    >> You might need to do some custom serialisation to reduce >> object allocation.
    >> Which SOAP implementation are you using?
    We are not using SOAP.
    It is a custom implementation and uses Castor Data binding tool for marshalling and unmarshalling.

    >> You may want to split some of the legacy access off so >> that you can cluster it seperately.
    Good suggestion, we would give it a try.

    >> -- DB Calls (Oracle JDBC driver).
    >> From the resultsets?
    >> Is your CMP engine caching where it can? Can you use
    >> optimistic locking for some access (does ATG support it?)
    Yes. The excessive memory memory allocation is in result sets.
    ATG provides caching and Optimistic locking. Infact I think I think ATG's OR mapping layer (called Repository) has many powerful features like Distributed caches, Query Caches etc.

    >> -- Object Serialization and Deserialization.
    >> Are you in a clustered environment?
    It is a good catch. Possibly it is, as we are in clustered env. and for session failover and replication the session gets backed up by the app server on every request. I need to study the Product documentation to find out if this is optimal or something needs to be done in code to reduce the work done in backing up sessions.

    >> Does the ATG container support Local interfaces or
    >> optimise out remote calls? If not, calling individual
    >> get/sets on entity beans is rather costly.
    Local interfaces are not supported yet. But remote calls can be optimized if the EJBs are looked in a properitary way. To stick standards we are not using the feature. Also, we do not do fine grained get/set but use a Value object pattern and make a single remote call on the Entity Beans.

    >> Does the ATG container hit the database for every
    >> get/set - or only at the beginning and end of TX?
    No. It is only at the begining of the transaction

    >> I have run Weblogic on JDk 1.4.1 with no probs
    We have tried running server with JDK1.4.1. It is not very reliable for a production system and we are stuck with JDK1.3.1 client Hotspot VM.
    I strongly agree with you the benefits that changing JVM version as against you trying to reduce Object creation should be preferred option.

    Thanks for really valuable suggestions.
  40. In deed, using J2EE to create distributed applications is much easier than it used to be (e.g. with C++ CORBA). Let's just whip up a couple of beans here and there and we have something working. Sometimes it is just easy to forget the overall architecture and the impact of distributing your application. Inexperienced developers will fall into this trap time after time, and why not even the pros.

    This is hardly J2EE's fault. Would you actually seriously consider using something else these days? (Ok. you might use .NET). The question is how you are going to use it. It does not mean that when things are awailable that you have to use them. Definately find out what the impact is for your application. Don't say that 'this was not supposed to do that', and then say it is J2EE that sucks.

    For example, when using CMP, don't expect it to solve any of your problems. They may be easy to develop but if you don't know when to use them, you will create a big mess.

    With CMP, you have study your application characteristics very carefully. CMP will barf on you if you use it with wrong kinds of apps. E.g if you return large result sets...something 50 can be large depending on your load.

    If your CMP cache is not able to do its work, it will be just another thing that will drag you down. You will just use incredible amounts of memory chaching results that are never going to be referenced again in a long time. Your cache will do incredible amounts of work trying to maintain your cache and trying to match your large result sets to the cached objects. Very very bad idea.

    Tuning is very important and you have to know when to limit your cache to last single transactions and so forth. You can find 10 fold speedups if you know the characteristics of your application and are able to tune your container accordingly.

    CMP is very good if you have small sets of data that gets referenced often, and I mean numerous times /min or /sec. For any many other uses, you have just created incredible performance problems. Bare stateless session beans + JDBC + SQL can be so much better (no memory used in caches, and large number of results become available very quickly). You can also try JDO or somethign comparable.

    So, don't blame J2EE. It can be easy to create apps, but it is easy to create problems at the same time if you do not know what you are doing. For example, I have yet to build an application that would only use CMP for database access. It just does not work that way.

    And something about code generation. You will give up level of control away and you probably have to accept some of the quirks that come with it. However, generation can reduce so much repetitive work that you would have to do by hand that it can be a real blessing. If you know what your generator is doing and you know it is something that would write by hand otherwise, then go for it. Something like Middlegen is excellent for CMP generation because you can go and edit the tool yourself to make it fit your special needs.

    My 2 cents.
  41. With CMP, you have study your application characteristics >very carefully. CMP will barf on you if you use it with >wrong kinds of apps. E.g if you return large result >sets...something 50 can be large depending on your load.


    Sure, J2EE data persistence debate is really becoming boring to me. CMP 1.1, 2.0, JDO, etc. We have "excelent" open source and commercial frameworks and tools following these specifications, but frankly...

    I have worked with proprietary OR mappings like PowerTier, WebObjects and EJB 1.1 (yes, Websphere...) but as a business developer I am, I never felt confortable by not using SQL. SQL and relational databases are being more mature and powerful for at least 20 years ago !

    And its very powerful way to get what you want from database, the primary concern of any business application. In this aspect I agree with Rolf arguments that J2EE specification folk some times appears to ignore field experience. Write business components ignoring SQL existence !?? They did distributed useless business components...It was a big mistake, IMHO. May be it's because Sun doesn't ship databases...

    So, the unique (but commercial) framework I know that give you the power of SQL back is... - guess who - Oracle !

    http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html.

    So, we could use Java OO business components with inheritance support but getting raw performance that any decent database today delivers. Just talk their language, SQL.

    Regards
  42. Couldn've been said better... It's like being a swimmer and blame your speedos for not swimming fast enough ;-)
    In companies I worked for the stories about "J2EE crap" and those "professionals" who's flooding them were almost like anecdots, always accompanied with significant amoung of laught.

    Anyway, thanks for shaking up this again.
  43. "It turns out that a major problem with J2EE is that it makes it easy to wirte distributed programs. The problem is that it is hard to design distributed programs."
    Well, wasnt this problem that J2EE was supposed to solve ? I strongly believe that this still is strong selling point for java, J2EE where one can get applications out in very short period of time.

    "Blaiming the infrastructure is an easy out, but it doesn't fly. There are too many examples of well done systems"
    From my experience of C++, CORBA where we had to build custom frameworks we had so much control over what framework would do, and I must say that this was much better than the J2EE applications shipping out in 4-6 months.
  44. "It turns out that a major problem with J2EE is that it

    >> makes it easy to wirte distributed programs. The problem is
    >> that it is hard to design distributed programs."

    >Well, wasnt this problem that J2EE was supposed to solve ?

    No. J2EE is an infrastructure fo r building distributed systems. You still have to know what you are doing to use it. There is no royal road to distrubted systems.
  45. My dear fella,
    I don't think U ever knew a few things about Java !!

    FIRST: Its a double-edged sword !! (Ever seen one??). And the baddest thing about it is that if suckers like U don't know how to weild it, U will cut u'r own throat (and also that of u'r sucking Company).

    SECOND: All the abstraction that is provided by the VM comes at the price of performance. Even Patrick Naughton (a former core member of the team that envisioned Java) admit that a same task done Using Java will run 15 to 20 times slower that the same done with C++. Its a question of knowing which technology to apply when. Meaning, Java is good only for Server-side technologies (remember AWT ??!!! Its no good)

    THIRD: If U have very little time-to-market, the cool abstraction and the different APIs provide U the ability to develop fairly complex applications pretty fast without having to worry about complex (sometimes wholly unnecessary) multiple inheritance. Meaning, the same application if developed using C++ would take 10 time more man-hours than developed using Java.

    FOURTH: I have switched to using OpenOffice instead of MS-Word and its working perfectly fine. Meaning, if U don't know how to dance, don't blame the dance floor.

    FIFTH: Java handle the ass-fucking task of memory management and clean-up for U; which C++ programmer have to do themselves and end up with a sore ass. Agreed that a badly written program in Java which overloads the garbage collector will crash. U have to use u'r memory jusdiciously.
    Meaning, instead of cursing the pioneers and developers of Java, who give U the APIs and the documentation and all these value added services like GC, VM abstraction, for free, U shoyuld thank them. LEARN TO RESPECT THE KINDNESS OF STRANGERS

    Back Off !!! and Learn to enjoy the taste of Coffee

    JGeek
  46. Amit,

    <Q>Meaning, instead of cursing the pioneers and developers of Java, who give U the APIs and the documentation and all these value added services..</Q>

    Do you mean: this Horrible Mess? Or is there any other ways to describe J2EE?

    Regards
    Rolf Tollerud
  47. HA, HA, HA,

    Is very funny reading ppl making statements about how bad JAVA is, have they ever designed a big system? how many man hours have they invested in creating the infrastructure needed for a big application?

    How many real big systems developed in corba are still alive?

    Use java... the infrastructre is in the box. (please read some books before)
  48. Pedro,

    <Q>making statements about how bad JAVA is</Q>

    This is my last post in this thread. I'm getting tired of this.

    I am not against Java, not even EJB.. Soon there will be similar big system for the .NET equally junk. The issue is:

    1) Do you want to put your system together using small modules from Open Source or commercial vendors or

    2) Do you want to use a giant dinosaur "Application Server"

    I find it unbelievably difficult to understand that there are a large number of experienced consultants (used to the principles of KISS) that are willing to put there life in the hands of something like Websphere.

    Bye

    Regards
    Rolf Tollerud
  49. <quote>
    The issue is:

    1) Do you want to put your system together using small modules from Open Source or commercial vendors or

    2) Do you want to use a giant dinosaur "Application Server"

    I find it unbelievably difficult to understand that there are a large number of experienced consultants (used to the principles of KISS) that are willing to put there life in the hands of something like Websphere.
    </quote>

    Rolf,

    You use strong language more often than necessary, but I wholeheartedly support your latest statement! This is exactly the issue, and I am an absolute proponent of option 1. During the last few years, I've "infected" most web developers I've come across.

    Practically every web developer and assumably many server-side developers do not need a full-blown application server like WebLogic and WebSphere. And the more this gets realized, the more attention will turn to the "little" J2EE gems like Resin 2.1 and Tomcat 4.1. Add Tyrex, Hibernate/OJB, Struts/WebWork, or your favorite JMS provider to the mix if you need to. And of course, a decent IDE like IntelliJ IDEA 3.0 (my absolute favorite), or NetBeans 3.4, or Eclipse 2.0.

    I keep repeating this: J2EE is not just J2EE-certified application servers. J2EE is a bag of technologies, enriched by lots of open source toolkits. Choose whatever suits your needs and your taste!

    Juergen
  50. Paul,

    I am not blaming Java; I'm only against the big J2EE application servers.

    I have used Java for period, but only for web projects with servlets, ordinary Java classes and stuff from Jakarta like tomcat, velocity, ant, OR tools and so on. All in all with good results and scalability. But you must understand that I do not particularly like being looked down upon by young J2EE guys,"which barf out tons of rad automatized code losing the grip onto every single inch of meaning into it", some of them having only a fraction of my experience in enterprise computing.

    I do not want to waist time learning something which I regard as a piece of shit, but on the other hand I have my career to think upon. With my views on J2EE, I was never going to make it in the Java world. So I was kind of forced out of Java.

    I am convinced that the fenomen of the "big Java Application servers" in time will be regarded like the tulip craze in the 17th century or more like Lysenkoism. In the case of Java, the J2EE guys have completely control over the three major components:

    control of scientific or techno press
    control of scientific appointments
    control of the education system

    Can the Java language survive this? I don't know.

    Regards
    Rolf Tollerud
  51. Rolf, I am glad you liked your experience with Jakarta Tomcat. I share your distaste for generated code, but may be not this viscerally.

    <quote>
    which barf out tons of rad automatized code losing the grip onto every single inch of meaning into it",
    <quote>

    But I havent lost all hope for you yet : I think the Java community can still make you love us. ;-) .Try the JMS api with OpenJMS. Asynchronous messaging is cool.I am sure you will enjout this API as much as I did.

    The trick to loving J2EE is to take it one small step at at a time. Eventually , I am sure you can learn it all. And then you will also know and appreciate why all that generated code or abstraction layers are useful!!

    Cheers!
  52. Manish,

    I am sure you mean well but your post illustrates my point perfectly. You’re misinterpreting "will not learn" with "can not learn". When you have the same level as I have with real life projects and real life architectural decisions you will not be so easily swayed by group pressure.

    A citation:

    "Under Lysenko's guidance, science was guided not by the most likely theories, backed by appropriately controlled experiments, but by the desired ideology. Science was practiced in the service of ideology. The results were predictable: the steady deterioration of Soviet biology. Lysenko's methods were not condemned by the Soviet scientific community until 1965, more than a decade after Stalin's death"

    Just change "science" with "J2EE", biology with Java.

    If you buy some expensive Sun boxes, put to have a big, bloated, slow and buggy piece of J2EE server (with a $50.000 price tag + 20% yearly licensing + consulting fees) between yourself and your customer and finish it of with a nice cheap Oracle database in the back..Well then you have just made one of the biggest mistakes of your life.

    This is the truth even if the J2EE theoreticians control (as the Lysenko did):

    the Java press
    the Java appointments
    the Java education system

    Regards
    Rolf Tollerud
  53. Rolf,
    I am not sure what you J2EE experience has been, however:

    >> If you buy some expensive Sun boxes, put
    We dont. We use cheap intel boxes. (J2EE doesnt require Solaris)
    We plan at some point, to use big iron boxes to consolidate our 100's of intel boxes as we gradually move our C++/COM server-side to Java. This is only possible with Java at this point in time.


    >> to have a big, bloated, slow and buggy piece of J2EE server
    Our chosen appserver is not slow.
    Moreover its much more reliable than software we tend to write.

    BTW: What does bloated mean? I always see it used in emotive arguments when someone is grasping for a criticism.


    >> (with a $50.000 price tag + 20% yearly licensing + consulting fees)
    We have never paid this sort of money.
    We have never required consultancy.

    Perhaps your experience is unique?

    -Nick
  54. Rolf,

    As a frequent (but critic) Theserverside reader, I must say : I like your style but I dislike some of your arguments. You wont find here or anywhere a panacea for you software development strategy, process or technology. J2EE and Java aren't panacea for anything, as also Corba, C++, .NET, etc

    If you have some requirement or even a full project specification, well, I could take your challenge. I'm sure many guys here also would love to deliver a killer implementation for your business application, whatever is it.

    I know you are a C# enthusiastic, so if you would like, I could deliver the user interface layer implemented in C# WinForms or VB.NET to reduce your training costs and culture clash because probaly you have some hungry .NET VB developers. Your developers could use visual inheritance to customize some visual aspects end behaviour of your application.

    Java will be at server side layers, it will easily run on Linux servers, it could be servlets and/or JSPs working within a MVC framework like WebWork and an object relational mapping framework like Hibernate or my own. If I think your application need some EJB's, or JMS features I will implement it too. But note that the application will support fault tolerance, load balance and a scalability and performance level that MEET your requirements. Of course, I will give you few application server choices to buy. Or may be your project could easily run on JBoss, that, I sure you know, it's free.

    As a software architect you are, you know, this is our job : deliver the customer business requirements ! The tech stuff is OUR job, no matter what IBM, BEA, Oracle or MS or even the company we work for dictate to us. The really smart developer knows how do your job.

    I could deliver any project on funcionality, budget, time and even some subjective requiriments because it's my job, and I'm very serious about it.

    So, for anything you want, give a chance to a right professional team. But please don't blame J2EE or Java or anything else just because you dislike it, right ?

    I was considering to contibute to some (my own) open source projects, but later I wondering if you need some help, so I'm realy prompt to anything you need ! Professionally ! Just pay for my services and I will solve all your problems, one by one, off course !

    PS : I give you what you want or your money back ! Seriously !

    Peace, and have funny about our miserable life !

    Rodolfo
  55. I have never worked with CORBA components.

    But I can see that the CORBA fans here either do not
    understand english or have not sense of net etiquette.

    This thread was created to be about what influences the
    performance of an J2EE server.

    People that use that for a general attack on J2EE
    and Java can not be taken serious.

    If people are not capable of something as simple as
    posting their opinions to a proper forum/thread, then
    I can not imagine them being capable of something as
    complex as understanding distributed server applications.
  56. Arne,

    <Q>People that use that for a general attack on J2EE
    and Java can not be taken serious</Q>

    Correction; The only suggestion is that time is running out for the "large J2EE/EJB Servers". For example so runs salesforce.com on very well on pure Java with Resin.

    I do not have the exact numbers but it is an extremely large and high performance site, aside from that, it is never down. I'm still waiting on something similar with a J2EE server.

    But you have to give compliments when compliments are due: theserverside was not down last night, a real improvement! keep on the good work..

    Regards
    Rolf Tollerud
  57. For those of you who dislike J2EE spec, look for new version of JBoss 4.0 due out sometime 2nd quarter of 2003. Based on a new AOP framework, JBoss 4.0 will allow you to design distributed applications that go way beyond the limitations of the J2EE spec.
  58. For the definitive guide to what influences performance of all servers READ THIS:

    http://www.jboss.org/blue.pdf