IIOP client settings that affect load balancing

In a cluster, the load balancing policy decides the algorithm used to map client naming requests to destination servers. While the load balancing policy can evenly distribute the initial client connections, long running IIOP clients can create unbalanced loads by building an affinity for the server that they are initially directed to by the name service. To avoid this problem, configure these settings in the client runtime:

• Socket reuse limit Limits how many times the client runtime reuses a network connection to call methods from one server. The default is 0, which indicates no limit. The default is inappropriate for a long-running client program that calls many methods from servers in a cluster. If sockets are reused indefinitely, the client can build an affinity for servers that it has already connected to rather than randomly distributing its server-side processing load among all the servers in the cluster. In these cases, tune the property to best balance client performance against cluster load distribution. In Sybase testing, settings between 10 and 30 proved to be a good starting point. If the reuse limit is too low, client performance degrades. The following table describes how to set this property for each client type:

  Client type	Property name
  Java	com.sybase.CORBA.socketReuseLimit
  EJB	com.sybase.ejb.socketReuseLimit
  C++, ActiveX, and PowerBuilder	ORBsocketReuseLimit You can also set the environment variable JAG_SOCKETREUSELIMIT.

• Idle connection timeout Specifies the time, in seconds, that a connection is allowed to sit idle. When the timeout expires, the ORB closes the connection. The default is 0, which specifies that connections can never timeout. The connection timeout does not affect the life of proxy instance references; the ORB may close and reopen connections transparently between proxy method calls. Specifying a finite timeout for your client applications can improve server performance. If many instances of the client run simultaneously, a finite client connection timeout limits the number of server connections that are devoted to idle clients. A finite timeout also allows rebalancing of server load in an application that uses a cluster of servers. The following table describes how to set this property for each client type:

  Client type	Property name
  Java	com.sybase.CORBA.idleConnectionTimeout You must also specify a garbage collection period by setting the com.sybase.CORBA.GCInterval property to an equal or lesser value. Connections are only closed when garbage collected.
  EJB	com.sybase.ejb.idleConnectionTimeout You must also specify a garbage collection period by setting the com.sybase.ejb.GCInterval property to an equal or lesser value. Connections are only closed when garbage collected.
  C++, ActiveX, and PowerBuilder	ORBidleConnectionTimeout You can also set the environment variable JAG_IDLECONNECTIONTIMEOUT.

• Connection timeout Sets a time limit to receive a server response before the connection fails over to try another server in the cluster. Setting this property ensures that failover happens without an unreasonable delay. Specify the timeout period in seconds. The default of 0 indicates no time limit. The following table describes how to set this property for each client type:

  Client type	Property name
  Java	com.sybase.CORBA.connectionTimeout
  EJB	com.sybase.ejb.connectionTimeout
  C++, ActiveX, and PowerBuilder	Not supported.

For information on setting client runtime properties for EJB, Java, C++, and ActiveX clients, see these chapters in the EAServer Programmer’s Guide:

• Chapter 8, “Creating Enterprise JavaBeans Clients”

• Chapter 12, “Creating CORBA Java Clients”

• Chapter 15, “Creating CORBA C++ Clients”

• Chapter 20, “Creating ActiveX Clients”

For information on PowerBuilder clients, see the PowerBuilder Application Techniques manual.

Copyright © 2005. Sybase Inc. All rights reserved.

View this book as PDF