3 Replies Latest reply on Feb 1, 2003 9:38 AM by Sacha Labourey

    Low performance clustering stateful SBs

    lumin Newbie


      I just did some test concerning clustering stateful SBs. Running a simple counter application on two computer cluster is much slower then on a single workstation (using JBoss v 3.0.6, using RoundRobin). The bean itself contains only one counter value.
      The client application initiates 50 client treads, each creating five beans, counting up to five. I measure execution time for each thread and compute mean time over all processes.

      v 3.0.5 it lasts ~45 seconds
      v 3.0.6 it lasts ~25 sec.
      v 3.0.6 single server ~10 sec. !?!? Any suggestions why?


        • 1. Re: Low performance clustering stateful SBs
          Sacha Labourey Master

          ?!? You are essentialy saying that *without* clustering, SFSB is quicker than with *clustered SFSB*, right?

          Than, yes that is logical, because we have to replicate the state between the nodes so that in case of a node failure, we can failover to the other nodes. For most cases, you can implement the isModified trick on your SFSB instance (see the doc for more info)



          • 2. Re: Low performance clustering stateful SBs
            lumin Newbie

            Yea actually that's what I wanted to say. Ok, it's logical, that there comes a certain amount of overhead along, which consumes CPU power and causes network traffic. But nevertheless from my point of view, it's not birdbrained to believe, that the same amount of work might be done faster, if it's shared between two computers (I used RoundRobin load balancing algorithm).

            Thanks a lot for your tip with the flag. I have to check it out. What about performance concerning entity beans.


            • 3. Re: Low performance clustering stateful SBs
              Sacha Labourey Master

              Remember a rule for clustering:

              1 + 1 != 2 (well not necessarly)

              It may also be possible to change a SFSB option in the future so that you use asynchronous replication but in this case you may sacrify correctness for speed.

              For SLSB, that's different though, you can really approch the "1+1==2" rule.