Tune ORB performance by setting ORB parameters and ORB thread pool parameters. You can often decrease response time by leveraging load-balancing, multiple shared connections, thread pool and message fragment size. You can improve scalability by load balancing between multiple ORB servers from the client, and tuning the number of connection between the client and the server.
The following table summarizes the tunable ORB parameters.
Table 3–4 Tunable ORB Settings
Path |
ORB modules |
Server settings |
RMI/ IIOP from application client to application server |
communication infrastructure, thread pool |
steady-thread-pool-size, max-thread-pool-size, idle-thread-timeout-in-seconds |
RMI/ IIOP from ORB to Application Server |
communication infrastructure, thread pool |
steady-thread-pool-size, max-thread-pool-size, idle-thread-timeout-in-seconds |
RMI/ IIOP from a vendor ORB |
parts of communication infrastructure, thread pool |
steady-thread-pool-size, max-thread-pool-size, idle-thread-timeout-in-seconds |
In-process |
thread pool |
steady-thread-pool-size, max-thread-pool-size, idle-thread-timeout-in-seconds |
Tune the following ORB parameters using the Admin Console:
Max Message Fragment Size: Messages larger than this number of bytes will be fragmented. In CORBA GIOPv1.2, a Request, Reply, LocateRequest and LocateReply message can be broken into multiple fragments. The first message is a regular Request or Reply message with more fragments bit in the flags field set to true. If inter-ORB messages are for the most part larger than the default size (1024 bytes), increase the fragment size to decrease latencies on the network.
Total Connections: Maximum number of incoming connections at any time, on all listeners. Protects the server state by allowing finite number of connections. This value equals the maximum number of threads that will actively read from the connection.
The ORB thread pool contains a task queue and a pool of threads. Tasks or jobs are inserted into the task queue and free threads pick tasks from this queue for execution. Do not set a thread pool size such that the task queue is always empty. It is normal for a large application’s Max Pool Size to be ten times the size of the current task queue.
The Application Server uses the ORB thread pool to:
Execute every ORB request.
Trim EJB pools and caches.
Thus, even when one is not using ORB for remote-calls (via RMI/ IIOP), set the size of the threadpool to facilitate cleaning up the EJB pools and caches.
Set ORB thread pool attributes under Configurations > config-name > Thread Pools > thread-pool-ID, where thread-pool-ID is the thread pool ID selected for the ORB. Thread pools have the following attributes that affect performance.
Minimum Pool Size: The minimum number of threads in the ORB thread pool. Set to the average number of threads needed at a steady (RMI/ IIOP) load.
Maximum Pool Size: The maximum number of threads in the ORB thread pool.
Idle Timeout: Number of seconds to wait before removing an idle thread from pool. Allows shrinking of the thread pool.
Number of Work Queues
In particular, the maximum pool size is important to performance. For more information, see Thread Pool Sizing.
Specify the following properties as command-line arguments when launching the client program. You do this by using the following syntax when starting the Java VM:
-Dproperty=value
When using the default JDK ORB on the client, a connection is established from the client ORB to the application server ORB every time an initial context is created. To pool or share these connections when they are opened from the same process by adding to the configuration on the client ORB.
-Djava.naming.factory.initial=com.sun.appserv.naming.S1ASCtxFactory
When using the context factory, (com.sun.appserv.naming.S1ASCtxFactory), you can specify the number of connections to open to the server from the client ORB with the property com.sun.appserv.iiop.orbconnections.
The default value is one. Using more than one connection may improve throughput for network-intense applications. The configuration changes are specified on the client ORB(s) by adding the following jvm-options:
-Djava.naming.factory.initial=com.sun.appserv.naming.S1ASCtxFactory -Dcom.sun.appserv.iiop.orbconnections=value
For information on how to configure RMI/IIOP for multiple application server instances in a cluster, Chapter 10, RMI-IIOP Load Balancing and Failover, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 High Availability Administration Guide.
When tuning the client ORB for load-balancing and connections, consider the number of connections opened on the server ORB. Start from a low number of connections and then increase it to observe any performance benefits. A connection to the server translates to an ORB thread reading actively from the connection (these threads are not pooled, but exist currently for the lifetime of the connection).