CORBA 2.6.1 Programmer's Guide for C++

server pool can share the same port. When configured this way, the server pool appears as a single IP host to the outside world.
A round-robin filter distributes the incoming connections among the communications processes in the pool. Because Parallel Library TCP/IP
does the load balancing, when you use it to configure Comm Server processes the LSD process has less work to do than it would if you used
separately configured logical Comm Server processes.
Use of Parallel Library TCP/IP also eliminates a message-system hop on each request. When this feature is configured, TCP data-path
functions ordinarily performed by a separate TCP/IP process are instead done by the user process, which references the Parallel Library TCP/IP
shared run-time library (SRL).
For further information about configuring Parallel Library TCP/IP with NonStop CORBA, refer to the NonStop CORBA 2.6.1 Administration
Guide.
Increasing the Number of Comm Server Processes
The Comm Server process serves as a network resource concentrator in large-scale systems by managing communication between network
clients and NonStop CORBA servers, thus reducing the demand for TCP/IP ports and connections. A single Comm Server process can handle
many network clients simultaneously. Comm Servers thus allow a NonStop CORBA server to be scalable relative to remote clients.
Using multiple Comm Server processes spreads the request workload for stateless objects over multiple processors, allowing the application to
handle larger volumes of traffic.
You can increase the number of Comm Server processes in two ways:
By using Parallel Library TCP/IP
By configuring multiple logical Comm Server processes
When you use Parallel Library TCP/IP, as described further under Using Parallel Library TCP/IP, you can scale each logical Comm Server
process up to sixteen processes, all listening at the same TCP/IP port. Load balancing among these processes is done by Parallel Library
TCP/IP by means of a round-robin algorithm.
When you configure multiple logical Comm Server processes, each Comm Server process listens at a different TCP/IP port. Each Comm
Server's address is independent of the others' addresses; multiple Comm Server processes can service the same IP address or subnet.
Load balancing among the logical Comm Server processes (except for those that are preconfigured for particular clients) is done by the LSD
process. This configuration provides scalability, but increases the time spent by the LSD process in distributing requests. If the Comm Server
processes are configured to use Parallel Library TCP/IP, the LSD uses a round-robin algorithm; otherwise, it uses a least-busy algorithm.
Parallel Library TCP/IP is the recommended alternative. If you do not use Parallel Library TCP/IP, it is recommended that you configure multiple
Comm Server processes to avoid performance bottlenecks. You can also use the two alternatives in combination if you need more than sixteen
Comm Server processes.
Using Multiple Instances of NonStop TCP/IP
If the TCP/IP process is a performance bottleneck, you can increase the number of external port connections available to your application by
doing the following:
1. Add multiple instances of NonStop TCP/IP to your NonStop CORBA system.
2. Assign your Comm Server processes, and also any application processes that are direct TCP servers, to multiple TCP/IP processes.
For TCP/IP configuration details, refer to the TCP/IP Configuration and Management Manual or the TCP/IP (Parallel Library) Configuration and
Management Manual.
Using Multithreaded Servers
If your server performs thread-blocking operations, writing a multithreaded server allows you to increase concurrency without incurring extra
process-creation overhead. For more information about multithreading in NonStop CORBA applications, see
Writing Multithreaded Applications.
However, if your server performs process-blocking operations—such as accesses to NonStop SQL databases—multithreading will not help. In
such cases, you can:
Configure your server as a server pool, as discussed under Using Server Pools.
Redesign your application to isolate the process-blocking operations, as discussed under Designing Advanced Applications.
Chapter 5. Tracing and Debugging Applications Chapter 7. Managing Transactions