Skip to main content

Visibroker Connection Management Settings Advice

  • February 16, 2013
  • 0 replies
  • 1 view

Problem:

  • Product Name: VisiBroker for Java
  • Product Version: 3.x, 4.x, 5.x, and 6.x
  • Product Component: ORB, Connection Management
  • Platform/OS Version: All

This article discusses basic guidelines for determining reasonable Visibroker server side connection management settings.

Resolution:

The VisiBroker connection management options allow the developer to be proactive about dealing with resource limits. These values are always tuned relative to the deployment environment. For example, a CORBA server deployed on an HP UX 11 host will be subject to kernel imposed thread and connection limits. The server side ORB connections, and VisiBroker threads are a subset of the total thread and connection usage of process.

The calculations are essentially as follows:

allowable resources = ((system limit) - (other) - (reserve))
recommended setting = min ((allowable resources), (peak client load))

where system limit is the limits imposed by the kernel, OS, or environment.

other is an estimate of the resources used by other non-VisiBroker parts of the application. For example JDBC will typically use sockets which contribute to the overall descriptor usage. If the other components can be configured explicitly then this number is predictable. If not, then an estimate must be made through analysis or simulation.

reserve is an estimated allowance for emergencies. 20% is a good starting point. This can then be tuned through simulation.

peak client load is an estimate of the number of clients that are expected to be using this server during peak load.

Some examples:

Example 1: The kernel limit for descriptors is 1024 per process, no other contributing factors are anticipated, and peak client load is expected to be 300 users. In this case it makes sense to set the appropriate connection max property to 300.

Example 2: The kernel limit for descriptors is 1024 per process, no other contributing factors are anticipated, and peak client load is expected to be 2000 users. In this case it makes sense to set the appropriate connection max property to 800. The server will actively manage connection to prevent hitting a system imposed resource limit.

There many ways to tune the behavior of VisiBroker.

The primary properties of interest for most deployments are the following. These are all explained in the documentation and release notes.

For Visibroker 3.x:
  ORBconnectionCacheMax  ORBconnectionMax   ORBconnectionMaxIdle
  OAconnectionMax  OAconnectionMaxIdle
  OAthreadMax  OAthreadMaxIdle
  ORBgcTimeout  ORBsyncGC
For Visibroker 4.x, 5.x, and 6.x:
  vbroker.ce.iiop.ccm.connectionCacheMax
  vbroker.ce.iiop.ccm.connectionMax  vbroker.ce.iiop.ccm.connectionMaxIdle
  vbroker.se.se.scm.scm.manager.connectionMax  vbroker.se.se.scm.scm.manager.connectionMaxIdle
  vbroker.se.se.scm.scm.dispatcher.threadMax  vbroker.se.se.scm.scm.dispatcher.threadMaxIdle
  vbroker.orb.gcTimeout  

The default se and scm are both "iiop_tp". So the most common form of these properties for most cases will be:
vbroker.se.iiop_tp.scm.iiop_tp.manager.connectionMax
vbroker.se.iiop_tp.scm.iiop_tp.manager.connectionMaxIdle
vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMax
vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMaxIdle

However, for the property vbroker.ce.iiop.ccm.connectionCacheMax issue in VBJ that need be aware can be found at [[knowledge_base: VBJ 4.5.1 & 5.x: vbroker.ce.iiop.ccm.connectionCacheMax is no longer in used (when removing client-side reference)]].
 
For more detailed discussion on related performance tuning, please read the wiki article [[wiki: VisiBroker Performance Tuning]].

#VisiBroker
#Security