Network Virtual Processors

As explained in Client/Server Communications, a client can connect to the database server in the following ways:

• Through a network connection
• Through a pipe
• Through shared memory

The network connection can be made by a client on a remote computer or by a client on the local computer mimicking a connection from a remote computer (called a local-loopback connection).

Specifying Network Connections

In general, the DBSERVERNAME and DBSERVERALIASES parameters define dbservernames that have corresponding entries in the sqlhosts file. Each dbservername parameter in sqlhosts has a nettype entry that specifies an interface/protocol combination. The database server runs one or more poll threads for each unique nettype entry. For a description of the nettype field, refer to The Connection Type Field.

The NETTYPE configuration parameter provides optional configuration information for an interface/protocol combination. It allows you to allocate more than one poll thread for an interface/protocol combination and also designate the virtual-processor class (CPU or NET) on which the poll threads run. For a complete description of this configuration parameter, refer to the IBM Informix: Administrator's Reference.

Running Poll Threads on CPU or Network Virtual Processors

Poll threads can run either in-line on CPU virtual processors or, depending on the connection type, on network virtual processors. In general, and particularly on a single-processor computer, poll threads run more efficiently on CPU virtual processors. This might not be true, however, on a multiprocessor computer with a large number of remote clients.

The NETTYPE parameter has an optional entry, called vp class, that allows you to specify either CPU or NET, for CPU or network virtual-processor classes, respectively.

If you do not specify a virtual processor class for the interface/protocol combination (poll threads) associated with the DBSERVERNAME variable, the class defaults to CPU. The database server assumes that the interface/protocol combination associated with DBSERVERNAME is the primary interface/protocol combination and that it should be the most efficient.

For other interface/protocol combinations, if no vp class is specified, the default is NET.

While the database server is in online mode, you cannot drop a CPU virtual processor that is running a poll thread.

Number of Networking Virtual Processors Needed

Each poll thread requires a separate virtual processor, so you indirectly specify the number of networking virtual processors when you specify the number of poll threads for an interface/protocol combination and specify that they are to be run by the NET class. If you specify CPU for the vp class, you must allocate a sufficient number of CPU virtual processors to run the poll threads. If the database server does not have a CPU virtual processor to run a CPU poll thread, it starts a network virtual processor of the specified class to run it.

For most systems, one poll thread and consequently one virtual processor per network interface/protocol combination is sufficient. For systems with 200 or more network users, running additional network virtual processors might improve throughput. In this case, you need to experiment to determine the optimal number of virtual processors for each interface/protocol combination.

Listen and Poll Threads for the Client/Server Connection

When you start the database server, the oninit process starts an internal thread, called a listen thread, for each dbservername that you specify with the DBSERVERNAME and DBSERVERALIASES parameters in the ONCONFIG file. To specify a listen port for each of these dbservername entries, assign it a unique combination of hostname and service name entries in sqlhosts. For example, the sqlhosts file entry shown in Table 13 causes the database server soc_ol1 to start a listen thread for port1 on the host, or network address, myhost.

The listen thread opens the port and requests one of the poll threads for the specified interface/protocol combination to monitor the port for client requests. The poll thread runs either in the CPU virtual processor or in the network virtual processor for the connection that is being used. For information on the number of poll threads, refer to Number of Networking Virtual Processors Needed.

For information on how to specify whether the poll threads for an interface/protocol combination run in CPU or network virtual processors, refer to Running Poll Threads on CPU or Network Virtual Processors and to the NETTYPE configuration parameter in the IBM Informix: Administrator's Reference.

When a poll thread receives a connection request from a client, it passes the request to the listen thread for the port. The listen thread authenticates the user, establishes the connection to the database server, and starts an sqlexec thread, the session thread that performs the primary processing for the client. Figure 28 illustrates the roles of the listen and poll threads in establishing a connection with a client application.

Figure 28. The Roles of the Poll and the Listen Threads in Connecting to a Client

A poll thread waits for requests from the client and places them in shared memory to be processed by the sqlexec thread. For network connections, the poll thread places the message in a queue in the shared-memory global pool. The poll thread then wakes up the sqlexec thread of the client to process the request. Whenever possible, the sqlexec thread writes directly back to the client without the help of the poll thread. In general, the poll thread reads data from the client, and the sqlexec thread sends data to the client.

For a shared-memory connection, the poll thread places the message in the communications portion of shared memory.

Figure 29 illustrates the basic tasks that the poll thread and the sqlexec thread perform in communicating with a client application.

Figure 29. The Roles of the Poll and sqlexec Threads in Communicating with the Client Application

Starting Multiple Listen Threads

If the database server cannot service connection requests satisfactorily for a given interface/protocol combination with a single port and corresponding listen thread, you can improve service for connection requests in the following two ways:

• Add listen threads for additional ports.
• Add another network-interface card.

Adding Listen Threads

As stated previously, the database server starts a listen thread for each dbservername that you specify with the DBSERVERNAME and DBSERVERALIASES configuration parameters.

To add listen threads for additional ports, you must first use the DBSERVERALIASES parameter to specify dbservernames for each of the ports. For example, the DBSERVERALIASES parameter in Figure 30 defines two additional dbservernames, soc_ol2 and soc_ol3, for the database server instance identified as soc_ol1.

DBSERVERNAME      soc_ol1
DBSERVERALIASES   soc_ol2,soc_ol3

Once you define additional dbservernames for the database server, you must specify an interface/protocol combination and port for each of them in the sqlhosts file. Each port is identified by a unique combination of hostname and servicename entries. For example, the sqlhosts entries shown in Table 14 cause the database server to start three listen threads for the onsoctcp interface/protocol combination, one for each of the ports defined.

If you include a NETTYPE parameter for an interface/protocol combination, it applies to all the connections for that interface/protocol combination. In other words, if a NETTYPE parameter exists for onsoctcp in Table 14, it applies to all of the connections shown. In this example, the database server runs one poll thread for the onsoctcp interface/protocol combination unless the NETTYPE parameter specifies more. For more information about entries in the sqlhosts file, refer to Connectivity Files.

Adding a Network-Interface Card

If the network-interface card for the host computer cannot service connection requests satisfactorily, or if you want to connect the database server to more than one network, you can add a network-interface card.

To support multiple network-interface cards, you must assign each card a unique hostname (network address) in sqlhosts. For example, using the same dbservernames shown in Figure 30, the sqlhosts file entries shown in Table 15 cause the database server to start three listen threads for the same interface/protocol combination (as did the entries in Table 14). In this case, however, two of the threads are listening to ports on one interface card (myhost1), and the third thread is listening to a port on the second interface card (myhost2).