CORBA 2.6.1 Programmer's Guide for C++

creation and invocation, you can ensure that the same code will operate correctly regardless of where the object is.
Static invocation or dynamic invocation. For example, whether the client will use a predictable set of object interfaces or might
find out about new interfaces at run time.
Object lifecycle. Issues such as creating, locating, and releasing objects, including how to use the Naming Service.
Server selection. For example, whether to request a specific server or use any server that can host an object interface.
Server pools. Implications of the use of server pools and whether the use of server pools must be transparent to the application.
Transaction management. Whether a client or object has responsibility for managing nested transactions.
Concurrency. Whether clients or an object must coordinate concurrent access to data, and whether the client requires threads.
Interoperability. For example, ensuring that a client developed on some other platform can interact with NonStop CORBA servers.
Tuning Applications for Performance
The following sections provide some performance tuning suggestions for NonStop CORBA applications.
Choosing the Most Efficient Transport Protocol
For remote object references, the IIOP protocol (which uses TCP/IP) must be used for transport. However, for local object references, NonStop
CORBA provides two proprietary transport protocols that can improve application performance:
GIOP over TS/MP, which addresses a stateless object through a server pool.
GIOP over the Guardian file system, which uses Guardian file-system addressing to access a specific instance of an object (that is, a
stateful object). Guardian file-system addressing uses a process name to specify a particular server process.
For object references that will always be local, HP recommends the use of GIOP over TS/MP wherever possible, since this protocol also
provides the availability, scalability, and load-balancing advantages of server pools. For local object references where GIOP over TS/MP cannot
be used, HP recommends using GIOP over the Guardian file system.
In addition to local object references, you can also use GIOP over TS/MP and GIOP over the Guardian file system for references to NonStop
CORBA objects on other NonStop systems that can be reached through the Expand network. In some cases, these two protocols may provide
an improvement in performance compared to IIOP over TCP/IP; however, the comparative performance in such cases depends on the
application and the network configuration.
GIOP over TS/MP is configured by using an application profile that sets
tsmp_server to TRUE. GIOP over the Guardian file system is configured
by using an application profile that sets
fs_server to TRUE. For further information about configuring these two protocols, refer to Application
Profiles: Configuring and Managing an Application.
Taking Advantage of Concurrency
If your application has the potential for concurrency (that is, it includes thread-blocking operations but not process-blocking operations), you may
be able to use multithreading to reduce the number of processes required to handle a given workload. For details, refer to
Writing Multithreaded
Applications.
If your application performs process-blocking operations, you can take advantage of process concurrency by using server pools.
Adjusting Process Priorities
In general, processes that provide services should have higher priority than processes that request those services. More specifically, consider
the process flow as a river at whose delta are services (both COS and application) or entity objects, whose tributaries are control objects, and
whose source streams are Comm Server, TCP/IP, and similar processes that are conduits for client requests. The delta should have higher
priority than the tributaries, and the tributaries should have higher priority than the source streams.
Adjusting Message-Buffer Sizes
Application performance is affected by the size of message buffers, particularly for remote operations. The most efficient buffer sizes are neither
extremely big nor extremely small.
You should design your IDL interface so that your messages are of reasonable size. For C++ programs, you can use the administrative
interfaces to adjust buffer sizes at run time through the
io_size configuration option. In general, large messages perform better with larger
buffers, whereas smaller messages perform acceptably well with the default buffer size.
Caution:
All processes that use GIOP over TS/MP or GIOP over the Guardian file system—that is, all processes that
use a protocol other than TCP/IP—to communicate with each other must share the same
io_size value.
Therefore, to change this value at run time, you must first stop all processes that use these protocols, change
the
io_size value, and then restart all processes. “All processes” can include processes associated with
different installations of NonStop CORBA, possibly even on different NonStop systems, if they use GIOP over
TS/MP or GIOP over the Guardian file system to communicate with each other.
The
io_size value can be changed for Java programs. You can adjust this value at run time for any C++
processes that communicate with processes written in Java.