Network Considerations

Ethernet is a collision detection based network i.e. there is no mechanism for reserving the network for a transmission, everybody sends at the same time and checks to see if there is a collision. If there is a collision then all colliding messages pause and then retry. These collisions cause individual messages to be delayed. Therefore, an excessive number of collision is a sign of an overloaded network.

If the network is overloaded then the network load can be reduced by introducing sub-nets. Typically this is achieved by adding network cards [either physical or virtual] to the servers. Not only does this increase the total network bandwidth to the server but can have the added benefit of increasing the fault tolerance of the system by introducing multiple connection paths to the server. Informix communicates with multiple cards by having multiple entries in the SQLHOSTS file.

The ethernet card assigned to the host will be used for all connections that have the INFORMIXSERVER to the appropriate dbservername. All client application connections are made through a poll thread, this can be network thread or a shared memory connection. If the client has connected over a tcp/ip connection (either sockets or TLI), the poll thread will monitor the port number allocated in the /etc/services file. A shared memory connection's poll thread receives requests through messages that are stored in shared memory.

The message will passed to the listen thread if the message is requesting a new connection. Upon receiving the new connection requests a listen port, tcp/ip connections only, the the file descriptor for the open port is passed to the poll thread. The poll thread is then responsible for future incoming messages from the application.

The listener thread uses a structure called a session control block, scb, to maintain information about the user's session. The session-id, the unique identifier for the session, is held and maintained by this structure. Additional structures are created to control the threads that are required for the user session, the thread control block (tcb). This thread holds the context information for the thread. Once all these tasks are complete the final task is to start an sqlexec thread for the session.

The sqlexec thread is responsible for sending messages back to the application, whereas the poll thread is responsible for receiving all future messages from the application. Usually a listen thread can handle 100 concurrent sessions, but if large number of connections are made simultaneously then the number of listen threads should be increased.

In the example above two listener threads will be started. A particular thread can be chosen by setting the INFORMIXSERVER to the appropriate settings and the aim is to ensure all the threads are doing the same volume of work.

While poll threads associated with shared memory have very little work to do, their main task is to start sqlexec threads, the same can not be said for network baased connections. If a large number of users are connecting over the network then multiple poll threads to handle incoming request may improve performance. The official line is each poll thread is capable of maintaining 200 users, although 50-100 is probably more accurate especially if the connections are network based.

The basic rule is SHM connections to CPU VP's, network connections to NET VP's.

If a poll threads runs on a CPU VP then there are NO busy waits on the VP (a busy wait is when the process spins attempting to avoid semop). Instead of spinning the CPU VP will run the poll thread. So rather than the CPU VP spinning needlessly wasting time, it is polling waiting on I/O and if still does not find work to do, then it will semop. When the NET VP notifies the CPU VP that a request has arrived the CPU VP will force a context switch. If both are running on the same CPU VP this is just a thread switch.

By default the poll thread runs every 10 thread switch. So if you are doing 1000 threads switch a second then you will be doing 100 poll calls a second.

The onstat -g ntu output, in conjunction with the netstat command, shows the network activity and this can be used to determine the number of network packets read and written by each thread. By comparing the statistics of the two commands then the percentage of network activity that is related to the database server can be calculated. Requests from the network can be rejected by the database and this can be seen seen from the onstat -g ntd. A reject can occur for a number of reasons but the most common problems are

• The number of users configured for the INFORMIXSERVER has been exceeded. HOW TO CHECK
• If the network is very busy the connection can receive network time out errors. HOW TOCHECK

Network timeouts can be controlled at an engine level by using the INFORMIXCONRETRY and INFORMIXCONTIME variables, but is rare for these to be changed from the defaults.