CORBA 2.6.1 Administration Guide

Note:
Although the figure shows a NonStop SQL/MP database, your application can access other types of databases.
Not all CORBA servers access databases.
This topic describes the issues involved in configuration management and performance tuning for NonStop CORBA application components.
Application Configuration Management
NonStop CORBA lets you use any of the following types of processes as application servers:
Stateless server pool
Stateful server pool
Single process
Whether a server runs as a server pool or as a single process depends on two configuration steps:
For a server to run as a server pool, you must define the server in a PATHCOM configuration file. It is in that file that you specify the
number of servers in the server pool and several other characteristics important for process management.
You should use scripts to configure and run your application servers. These scripts are similar to the scripts that you use to start and run
the NonStop CORBA system. In the scripts, you configure your servers in the same way the NonStop CORBA system processes are
configured.
For all types of servers, you indicate which protocols the server will support in the server's configuration profile. You define the protocols
in the configuration database by using the configuration tool. For example, a server that is specified as using the TS/MP protocol runs as
a server pool.
Whether a server pool accepts stateless or stateful requests depends on whether its object classes require stateless or stateful processing.
In NonStop CORBA, objects can be either stateful or stateless. If an object is stateless, each method invocation for the object can be handled
by a different server process in the pool. A stateless object cannot maintain state information in memory between calls, because the state
information would be available to only one process. Note that stateless objects typically make sense only when hosted in a server pool.
If an object is stateful, the first method invocation for the object goes to any free server process in the pool, and any subsequent requests go to
that same process. A stateful object can maintain state information in memory between method invocations, because only one process needs
access to the information.
The same server pool can host both stateless and stateful objects. The distinction between stateless and stateful is made regardless of whether
the object is in a server pool or in a dedicated single server.
Note:
For the purpose of this discussion, a server pool is stateless if it hosts only objects that require stateless
processing; it is stateful if it hosts one or more objects that require stateful processing.
From an ORB method-routing viewpoint, stateless requests are much more efficient than stateful requests because of the queuing efficiency
that TS/MP can provide (analogous to a single line for all bank tellers rather than one line per bank teller). This factor makes it attractive to
design classes to be stateless to maximize throughput.
However, in some cases, it would be inconvenient or costly for an object to be stateless. For example, if an object returns the results of a large
SQL query to a client using a cursor, the client must make multiple method invocations on the server. If the object is stateless, subsequent
method invocations could reach different server processes, each of which would have to repeat the original query.
Stateless and stateful server pools are managed by TS/MP, which provides for scalability and load balancing by allowing multiple processes to
work in parallel to perform the same task. TS/MP also provides for availability: its monitor process, called PATHMON, automatically restarts a
process that fails. Because TS/MP provides all process management for the NonStop CORBA system, you use TS/MP interfaces for either the
line-oriented PATHCOM utility or the corresponding programmatic interface (based on the SPI) to configure and manage the NonStop CORBA
system processes. The same holds true for any NonStop CORBA application process that you configure as TS/MP processes.
Application Performance Tuning
Application performance tuning for NonStop CORBA application servers includes:
Determining the best relative locations of clients, servers, and data
Managing application server pools
Server-pool management includes deciding how many server processes each pool requires and detecting when a performance problem results
from a factor other than an insufficient number of server processes.
In general, performance tuning of stateless server pools is straightforward. Provided that you define the server pool in your PATHCOM
configuration file to allow a sufficient number of server processes, TS/MP can automatically add and delete processes to accommodate changes
in workload (just as a store varies the number of clerks on duty). You can use PATHCOM to study the utilization of processes in the pool and to
help you decide if you need to increase the maximum number of configured processes.
Tuning stateful server pools is more complex. Because all requests to a specific object go to the same process for the duration of a request
(even if other processes in the server pool are idle), TS/MP cannot completely balance the workload across the servers in the pool. Requests to
different instances of the same object class can be balanced across processes in a server pool, but requests to the same instance, by one or
more clients, must go to the same server. Because of this limitation, some server processes might be overworked while others sit idle.