Gene, > Clustering improves scalability of multiple requests and > reliability/failover of individual requests, but will > almost always decrease the performance of individual > requests simply due to the intrinsic cluster overhead.
I agree with the first part of your statement, but disagree with the latter part. The intrinsic cluster overhead you are talking about I guess comes from your experiences with WebLogic? I could be wrong here - but I believe WebLogic has the concept of creating cluster and/or replica aware stubs for clients. And therefore there is an overhead when (a) the client looks up a home (among those available in a cluster) and/or (b) when the client invokes a method on the EJBObject (which can again be clustered) But using the above to generalize on clustering features provided by other vendors would be an injustice. With our AppServer for example, our client stubs are cluster aware (with load balancing and failover built in) implicitly. That is, you do not need to [re]compile them for them to be cluster/replica aware. And we do not hard code host/port numbers (as do many other products). Also we do not require that clustering be homogeneous. That is, you can cluster heterogeneously as well - without ever needing to recompile your stubs or skeleton code. But that's getting away from the point I was trying to make. In the Borland Enterprise Server (built on top of VisiBroker), clients (by default) round robin between servers. Once a connection is established, the client 'sticks' on to that server for the duration of its (or the server's) lifetime. You could round robin on every request from that client, but this could mean that the overhead associated with looking up a [remote] object everytime prior to using it will negate any performance benefit. We avoid this. The only overhead that will be incurred by our product is when a server crashes and clients [using that server] have to fail over to another server. (The logic to do this is in our stubs). Also, our runs with ECperf have proved that the throughput was increased by running two Containers. This allowed one Container to serve requests while the other was blocked (say servicing other requests or in the midst of a garbage collection run etc). -krish PS: One on a similar vein, caches replicated across a cluster could be effective (as you pointed out) - but since clients typically exhibit locality of reference, this would mean that after a certain period of activity (since servers are typically long running processes), the caches would be pretty much replicated across servers anyways. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
