Performance and scalability: Better Response Times on WebSphere Cluster

  1. Better Response Times on WebSphere Cluster (4 messages)


    We have our web application deployed on a Cluster of 2 IBM
    WebSphere 4.0.4 Application Servers on Sun Solaris boxes.
    Clustering was achieved using "Horizontal Cloning" of the
    Application Servers. Our application does not have EJBs and
    the objects in session are persisted on a DataBase. The
    problem we are facing is POOR RESPONSE TIMES. We have tuned

    1. Connection Pooling parameters for both Application and
    Session DataSources.
    2. Web Container threads on both the machines.

    When Load/Performance Testing was done using Rational
    Robot, the response times were not satisfactory as compared
    when the application was deployed on a Single Server. This
    defeats the very reason of going for a Custer - Scalability
    with minimal Response Times.

    Any help/pointers/suggestions with respect to WebSphere
    Cluster will be greatly appreciated.

    Thanks and Regards,
    Sudharshan Govindan
  2. Hi Sudharshan,

    Unfortunately, that is often what happens in a cluster. When moving from a single server environment to a clustered environment there is typically a performance hit from the disabling of caches. This is due to the added complexity of a clustered environment.

    One of the main reasons that people suffer from performance degredation when moving from a single server environment to a clustered environment in WebSphere is that in a clustered WebSphere environment persists the HTTPSessions in the DataBase. That means after every modification to a Session object WebSphere (behind the scenes) makes a DB call to update the DB in synch with the modification to the Session object.

    If you want to avoid such a bottleneck I would point you to Tangosol Coherence which has an HTTPSession Replication Module for WebSphere which replicates the Session objects in-memory across the cluster. This avoids the costly DB calls and provides fail-over of the Session data.

    Further, Coherence provides the ability to synchronously cache/store data/objects in-memory in a clustered environment. It implements cluster-wide locking and event notification. Replicated and Distributed caching strategies are both supported through a java.util.Map interface.

    Rob Misek
    Coherence: Easily share live data across a cluster!
  3. The method of session persistance you describe is but one option for session persistance available in WebSphere. Yes, you can configure it so that is persists at every change to an object stored in the session, but by default it only stores the session at the end of the service method.

    Before suggesting a blanket caching strategy (which can be useful in many situtations), perhaps it would be a better idea to look at the following:

    1) Is session persistance even needed? Session persistance may not be needed, if the sessions are not critical to the system. If they aren't needed, turn it off! I'm assuming that it is needed however, as persistance isn't on by default

    2) It would be wise to optimise the objects that you are storing in your session. If you are noticing such a downturn in performance, then it may be that you are storing unnecessary information in your session object. You may find that if you are storing many small objects in your session, that you get a performance improvement by moving to multi-row database persistance. In such a case, each object stored in the session is held as an individual row in the database, rather than a row-per-session that is the default configuration.

    3) Determine whether you really need to store the session at the end of every service method - if this is not critical, move to a code-controlled session persistance, where you tell the session when to persist.

    4) Place the database for the session persistance on a separate server than your application database. In this way, database load on your application will not impact on the performance of the session database.

    If you still do not have the performance you need after looking at these options, then a caching strategy may well be something to look at, but it's certainly not the first port of call.

    Anyway, hope that helps!
  4. Excellent points!

    One other trick is to use "holder" objects for loadable data, i.e. data that you want to store in the session but don't need to be replicated. For example, instead of putting your "BigData" objects into the session directly, put them in a holder:

    class MyBigDataHolder implements Serializable {
      public transient BigData bigdata;

    Now you can "get" the session attribute, and modify its value "in place" (the field itself) instead of doing a "put" back into the session (which would force persistence and/or replication)!

    Probably half the data, in terms of count, and maybe 80% or so in terms of size will fall into this category (things that could be loaded from a backing store if necessary).

    To make sure that the other half is repliated reliably and efficiently, definitely check out how our Coherence product can transparently handle your HTTP session load. (Not to mention the rest of your application's caches ;-)


    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  5. Sorry, I forgot to point out that by making the field "transient", the holder itself will get moved, but the big data that sits inside it will not get moved. The result of this is that data that can be reloaded on the other server will not get session persisted / replicated.


    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!