Discussions

News: WebSphere 6.0 high availability with shared file systems

  1. IBM WebSphere 6.0 has some of the most advanced high availability features on the market. I've just added a blog entry on how the transaction manager takes advantage of this new infrastructure (HAManager) to provide in doubt transaction recovery in around 12 seconds on commodity hardware.

    See the blog entry at http://www.billynewport.com

    NOTE: Billy Newport is an IBM engineer

    Threaded Messages (25)

  2. commodity hardware....[ Go to top ]

    pleae donot say commodity hardware as websphere require at least 1GB ran to boot its services without any load and another to give u something usefull
  3. commodity hardware....[ Go to top ]

    My kids computer has a gigabyte of memory, come on ;) Blades have 4GB of memory. Large servers come with a lot more. Plus, WAS scales very well vertically when compared to the competition (up to at least 8 processors) so you don't need to run multiple JVMs on a SMP box to get the CPU power which saves memory. Go look at old specj benchmarks for proof of that, we always ran a single JVM on up to 4 ways while the competition always used more. I usually run WAS with 256MB heaps for small workloads. More work load takes more memory.

    Memory footprint is a big focus point for 6.0 but the trade off ends up being low memory footprint with low performance versus a little larger footprint and much better performance. We had many discussions internally over these issues. One requirement was the smallest memory footprint and another was good out of the box performance. Hard to do both. Depends on the definition of 'good'.

    Niether the DM nor the node agent are required to be running in 6.0 for normal stable usage. Use your own process nanny instead of the node agent if you want. The DM is only needed for config changes as is the node agent (or do manual syncs and don't use the node agent at all).

    Billy
    IBM
  4. commodity hardware....[ Go to top ]

    I use WAS with my 1GB ram workstation and i must confess that it works pretty fine.I've seen other colleages using 256 RAM on their pc to run WAS and I am very happy am not in their place.

    But when you have a team of 10-20 developers each needing a workstation equiped with 1GB ram to run WAS then it is kind of an added expense to make use of WAS.

    regards,
       javed
    http://javedmandary.blogpsot.com
  5. Vertical Scaling[ Go to top ]

    Plus, WAS scales very well vertically when compared to the competition (up to at least 8 processors) so you don't need to run multiple JVMs on a SMP box to get the CPU power which saves memory. BillyIBM

    PMI, but is not vertical scaling a function of the JVM ? A Java application by itself can do precious little.

    thanks
  6. Vertical Scaling[ Go to top ]

    PMI, but is not vertical scaling a function of the JVM ? A Java application by itself can do precious little.thanks
    SMP scalability can be achieved only if all SW layers achieve it.
    So you need:
    1 : a scalable OS
    2 : a scalable JVM
    3 : a scalable J2EE container

    It is far too easy for any layer to grab a big lock, serialize everything and jeopardize scalability.
    So it's a valid claim for a J2EE container to be "SMP scalable"

    Jacques Talbot - Teamlog
  7. Vertical Scaling[ Go to top ]

    3 : a scalable J2EE containerIt is far too easy for any layer to grab a big lock, serialize everything and jeopardize scalability.So it's a valid claim for a J2EE container to be "SMP scalable"Jacques Talbot - Teamlog

    Right, but I am trying to understand his statement regarding optimal utilization of CPUs with one-process app vs. when split in several processes.

    Grabbing a big lock is simply not realistic. Containers like Weblogic are mature and I would safely assume that they do not acquire unnecessary locks. And if they did acquire a lock and serialized access, probably the same serial semantics would hold if it were run as several processes.

    May be a more realistic scenario justifying his statement will help.
     
    Thanks
  8. Vertical Scaling[ Go to top ]

    The JVM will only get you so far. You need to make sure you have a carefully coded application in terms of datastructures and synchronized blocks for maximum concurrency so that you can use a lot of threads and get more throughput. We have done significant work in this area and it shows in our vertical scaling. No doubt, other vendors are doing similar. Any statement of X is better than Y is always a point in time statement. Y invariably does it better in the next version and the race continues.

    Billy
  9. commodity hardware....[ Go to top ]

    On a quite different subject, I was wondering if debugging is now feasible with a standalone version of Websphere. I am an IDEA user, and I hate having to use the horribly slow and un-functional WSAD just to be able to debug my system (or the abominous new Rational SDP version 6, which horribly choked for hours trying to digest my project's files): when I tried it, WAS 5.1 in debug mode was incredibly slow both on Linux and Windows, apparently because the IBM VM can't work with JIT compiler activated in debug mode.
  10. On a quite different subject, I was wondering if debugging is now feasible with a standalone version of Websphere. I am an IDEA user, and I hate having to use the horribly slow and un-functional WSAD just to be able to debug my system (or the abominous new Rational SDP version 6, which horribly choked for hours trying to digest my project's files): when I tried it, WAS 5.1 in debug mode was incredibly slow both on Linux and Windows, apparently because the IBM VM can't work with JIT compiler activated in debug mode.

    To debug at full speed in WebSphere you need to make sure that IBM's JVM has it's JIT turned on (-Xj9). Why exactly this is an option and not the default is beyond me. With the JIT turned on remote debugging with Websphere is painless and fast. In fact I used IntelliJ 4.x to debug and it works great. Here's a how-to...
     
    http://www.theserverside.com/news/thread.tss?thread_id=29379#142784
  11. IBM J9 JVM -- commodity hardware....[ Go to top ]

    To debug at full speed in WebSphere you need to make sure that IBM's JVM has it's JIT turned on (-Xj9). Why exactly this is an option and not the default is beyond me.

    This option does not enable the JIT, it invokes an entirely different VM implementation called J9 (the old one is called "Classic" and also has a JIT) that happens to have features making it good for debugging. However, as you may notice if you start testing it heavily, it is not mature enough to be the default option.

    J9 has been used for some time in the J2ME space and now seems to be IBM's future choice for J2SE/EE as well. However, I have no idea why IBM has decided not to go public with this fact.
  12. On a quite different subject, I was wondering if debugging is now feasible with a standalone version of Websphere. I am an IDEA user, and I hate having to use the horribly slow and un-functional WSAD just to be able to debug my system (or the abominous new Rational SDP version 6, which horribly choked for hours trying to digest my project's files): when I tried it, WAS 5.1 in debug mode was incredibly slow both on Linux and Windows, apparently because the IBM VM can't work with JIT compiler activated in debug mode.
    To debug at full speed in WebSphere you need to make sure that IBM's JVM has it's JIT turned on (-Xj9). Why exactly this is an option and not the default is beyond me. With the JIT turned on remote debugging with Websphere is painless and fast. In fact I used IntelliJ 4.x to debug and it works great. Here's a how-to... http://www.theserverside.com/news/thread.tss?thread_id=29379#142784

    Oh, god, I love you, many thanks.
  13. Developer tools[ Go to top ]

    Hi Billy -

    IBM really needs to improve its development tools in WSAD!

    To run up a simple web application on WebSphere running on a twin Xeon 2.7GHz machine with 1Gb RAM, startup time of the server is of the order of 30s-1 minute. When debugging it's even slower (nearly two minutes) and some memory leak causes an OutOfMemoryError if you restart a project more than a few times.

    This is ridiculous when I'm reading about sub 5-second startup times of other web/app servers for test purposes and it's a serious drag on productivity. WSAD alone is chewing over 400Mb of RAM on my machine and WS is taking up a further 200Mb or so.

    I know this isn't your area, but that's what you get when you post adverts on community sites.

    Chris Marshall
  14. Manual sync[ Go to top ]

    "do manual syncs and don't use the node agent at all"

    Do you mean copying all the xml files?
  15. Manual sync[ Go to top ]

    No,
    use the syncnode command line utility. This will update the local respository. This can only be run when the node agent is not running.

    Billy
  16. Old benchmarks...[ Go to top ]

    Go look at old specj benchmarks for proof of that, we always ran a single JVM on up to 4 ways while the competition always used more.

    Which one of the "old" ones are you referring to?

    This: (http://www.spec.org/jAppServer2002/results/res2003q1/jAppServer2002-20021211-00002.html) 5x2 CPU's of WAS 5.0.

    This: (http://www.spec.org/jAppServer2002/results/res2003q1/jAppServer2002-20030205-00004.html) 7x2 CPU's of WAS 5.0.1

    This:
    (http://www.spec.org/jAppServer2002/results/res2003q4/jAppServer2002-20031111-00020.html) 9x2 CPU's of WAS 5.1

    Or this:
    (http://www.spec.org/jAppServer2004/results/res2004q2/jAppServer2004-20040512-00003.html#JVMJava(TM)_2_Runtime_Environment,_Standard_Edition_(build_1.4.1)0) 11x2 CPU's of WAS 5.1
  17. SPECjAppServer Scaling Facts[ Go to top ]

    WAS scales very well vertically when compared to the competition (up to at least 8 processors) so you don't need to run multiple JVMs on a SMP box to get the CPU power which saves memory. Go look at old specj benchmarks for proof of that, we always ran a single JVM on up to 4 ways while the competition always used more.

    You're using SPECjAppServer results to support your claim that WAS scales very well compared to the competition? Baloney!

    First, it's false to say that the competition always used more than a single JVM on up to 4 ways, as anyone can verify for themselves in the published results at http://www.spec.org/osg/jAppServer2002/results/jAppServer2002.html . Look at the (number of) instances in the EJB Container section and compare that to number of J2EE Application Server systems. Only configurations including 8-ways and up used more than a single instance.

    This claim is more than a little disingenuous, since no IBM WAS SPECjAppServer results have been published using anything larger than a 4-processor system. In fact, all but one WAS result for each of the SPECjAppServer2002 and SPECjAppServer2004 benchmarks have used 2-processor systems.

    The one WAS SPECjAppServer2002 result using a 4-processor application server system, used two 4-processor systems to achieve a result of 448.12 TOPS@MultipleNode and $647.52 US$/TOPS@MultipleNode.
      http://www.spec.org/osg/jAppServer2002/results/res2003q2/jAppServer2002-20030610-00010.html

    Compare this to the result achieved using BEA WebLogic Server on two 2-processor systems - 694.88 TOPS@MultipleNode and $262.87 US$/TOPS@MultipleNode.
      http://www.spec.org/osg/jAppServer2002/results/res2003q3/jAppServer2002-20030708-00012.html

    The disparity is even greater at higher throughputs. The highest throughput by IBM WAS in a SPECjAppServer2002 result required nine 2-processor systems (and 9 JVM instances) to achieve 2575.34 TOPS@MultipleNode and $330.07 US$/TOPS@MultipleNode.
      http://www.spec.org/osg/jAppServer2002/results/res2003q4/jAppServer2002-20031111-00020.html

    Compare this to the results achieved using BEA WebLogic Server on only four almost identically configured systems (and 4 JVM instances) - 3096.49 TOPS@MultipleNode and $157.66 US$/TOPS@MultipleNode.
      http://www.spec.org/osg/jAppServer2002/results/res2004q3/jAppServer2002-20040720-00026.html

    In the interest of full disclosure, I am a BEA employee. However, the results speak for themselves. See for yourself at:
      http://www.spec.org/osg/jAppServer2002/results/jAppServer2002.html

    Steve
  18. Scalability?[ Go to top ]

    Steve,

    http://e-docs.bea.com/wls/docs70/perform/WLSTuning.html#1123656

    http://e-docs.bea.com/wls/docs81/perform/WLSTuning.html#1123656

    For both WLS 7 and 8.1, it says that I should start a WLS instance for every 2 CPU's. Scalable?

    And the link that you provided has a 12-way DBServer (MSSQL) going along the 4 WLS nodes on 2*2 CPU hosts. If it requires 3 times the number of DB CPU's to the number of J2EE Server CPU's, is it really scalable?
  19. Scalability?[ Go to top ]

    For both WLS 7 and 8.1, it says that I should start a WLS instance for every 2 CPU's.

    I wonder why an SMP box needs multiple WLS instances? Maybe it has something to do with scheduling or swap? In theory one JVM can exploit as many CPUs as there are running threads, so there hopefully wouldn't be a need for additional WLS instances.
  20. Scalability?[ Go to top ]

    For both WLS 7 and 8.1, it says that I should start a WLS instance for every 2 CPU's.

    I wonder why an SMP box needs multiple WLS instances? Maybe it has something to do with scheduling or swap? In theory one JVM can exploit as many CPUs as there are running threads, so there hopefully wouldn't be a need for additional WLS instances.

    Simple: Years ago, the JVMs weren't very good. That's when the field guys figured out to run more than one JVM. A year later, it finally made it into the doc. A half year later the doc was finally released. About the time that it didn't matter as much anymore ;-)

    And since version X doc is version (X-1) doc plus tweaks, it will take many years for it to disappear from the docs.

    In other words, quoting doc as proof of point-in-time best practices is a poor choice.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  21. Scalability?[ Go to top ]

    For both WLS 7 and 8.1, it says that I should start a WLS instance for every 2 CPU's.
    I wonder why an SMP box needs multiple WLS instances? Maybe it has something to do with scheduling or swap? In theory one JVM can exploit as many CPUs as there are running threads, so there hopefully wouldn't be a need for additional WLS instances.
    ... About the time that it didn't matter as much anymore ;-)And since version X doc is version (X-1) doc plus tweaks, it will take many years for it to disappear from the docs.In other words, quoting doc as proof of point-in-time best practices is a poor choice.

    I hear your claim that WebLogic's SMP manual is outdated. But I'm still eager to learn if my naive suspicion is correct that a single container instance is optimal for an SMP box. Does anyone here know?
  22. Scalability?[ Go to top ]

    The WLS documentation for 8.1 does not actually say that 1 server instance per two CPUs is optimal. Instead, it tries to suggest a methodology for determining how many instances are optimal. For best performance on internal benchmarks, we usually run a single instance on 8-cpu systems.

    As Cameron says, earlier JVMs had issues scaling, and we used to recommend a ratio of 1 instance for every 2 CPUs.

    I think the documentation can be clearer on these points. I'll see if I can get that fixed. Thanks for the feedback.

    Thanks,
    Craig
    --
    Craig Blitz
    Performance Manager
    BEA Systems
  23. Scalability?[ Go to top ]

    Its mainly to do with GC.

    By running multiple JVM's with individually smaller heaps, the gc perf is much improved. You have smaller heaps to scan, and you effectively have parallel gc, albeit in parallel vm's.

    Now, since we have VM's that do parallel gc, this performance trick may not be as optimal as it used to be...

    -Nick
  24. Scalability?[ Go to top ]

    Simple: Years ago, the JVMs weren't very good. That's when the field guys figured out to run more than one JVM.

    JVM has only been around for 10 years, and BEA and IBM have developed their own version of it for the last 3 (BEA)and circa 6 (IBM) of them, so blaming the JVM is actually worse, since they have been able to make it scalable for some time.
  25. SPECjAppServer Scaling Facts[ Go to top ]

    Man,
    We're touchy, who mentioned BEA? You're not the only competition out there, take a minute and look over your shoulder.

    I also said in a later response on this subject that no doubt the competition scales well now because any statement on relative performance is a point in time statement. I don't see you making a similar statement in your post that "no doubt WAS 5.1.1/6.x is faster now so these benchmarks aren't so valid anymore".

    BTW, when are you going to post a Specj 2004 number? Any reason you haven't published yet :)

    Interesting though. This JVM scaling post caused the reaction rather than the actual main topic of this thread.

    Peace.
    Billy
  26. Hello

      With WAS 6, is there a way to program a real Java Thin Client to connect on WAS. I say real Thin Client because in all IBM documentation, any java client should use what they call ‘WebSphere Application Server Application Client’. This App Client launches the java applications and will use around 30 Meg of Jar to be able to do RMI/IIOP and JNDI on WAS. This is not a 'small foot print' application.

    I haven’t seen any official IBM document on how to setup small foot print Thin Client with proper jars to connect on WAS.

    Any comments will be welcome.

    Thank you.