Uniface Router Configuration

The Uniface Router architecture can be quite complex, depending on how it is configured. For example:

• At startup, the Uniface Router initiates network listen threads on configurable port numbers for up to four different networks. You can specify different network protocols, or the same protocols with different port numbers, or a combination. The port numbers are used by both clients and servers to connect to the Uniface Router. For more information, see Stop and Start the Uniface Router.
• It is possible to have more than one Uniface Router on a machine, each working independently with its own group of servers. It is also possible for one Uniface Router to relay requests to another Uniface Router, known as Router hopping (although this can degrade performance).
• The Uniface Router may start a Uniface Server as a shared server, which can process requests from multiple clients, or as an exclusive server, which has a direct connection with only one client. The exclusive server's connection with the client may be inherited from the Uniface Router, or it may have its own listening port. For more information, see Shared and Exclusive Servers, Logical and Physical Connections, and Network Connection Endpoints.
• A Uniface Router can use Uniface Servers on other machines. The Uniface Router can only start Uniface Servers on the same machine where it is running, so servers on other machines must be started by other means. However, such servers can then register with the Uniface Router so that it can use them. For more information, see Starting Uniface Servers.

Many configurations are possible but the more steps involved in getting a message from the client to the server and back again, the more performance deteriorates.

For more information, see Configuring the Uniface Router.

Load Management

The Uniface Router enables you to adjust the number of servers that the Uniface Router uses so that you can optimize the way the server load is handled.

By default the Uniface Router looks for a server that is currently idle that can fulfill a client request. It determines this on the basis of criteria such as the user name, the UST, the network connector, and whether a shared or exclusive server is required. If there is a choice of servers, the Uniface Router gives each request to an available, matching server that has already handled the most requests. If no server is available, it starts a new one. During peak times, this can create a pool of Uniface Servers handling incoming client requests.

To manage the load, you (as the deployer) can specify the maximum number of servers or the maximum number of a particular server type (UST). When either of these limits is reached, the Uniface Router queues the client requests rather than starting new servers, and passes them to servers as they become available. However, this may produce unacceptable delays for some clients. For more information, see $MAX_SERVERS and /max.

A more dynamic way of handling the situation is to allow the Uniface Router to start servers as needed, but to define a maximum time that a server can be idle. Because the Uniface Router gives each request to the server that has already handled most requests, many servers become idle as the load diminishes. By setting a maximum idle time, you can ensure that you do not have too many active servers. However, you need to ensure that the maximum idle time is long enough to prevent them from being stopped and restarted when the next burst of client requests is received. For more information, see /maxidle.

Data Compression

Transporting large amounts of data from servers to clients can result in performance problems. A possible solution is to reduce the size of the data being transferred by compressing it. This has to be balanced against the CPU time required to perform the compression. You can use the $NET_FMT setting to specify the data compression format of hit data returned from server to client. For more information, see $NET_FMT.

Uniface Router Threads

The Uniface Router is a multi-threaded process. You can calculate the number of threads that each Uniface Router process consumes at a particular moment:

• One main thread.
• One additional thread for each TCP or TLS port to which the Uniface Router listens.
• One additional thread for each client connection. Potentially, there could be one thread per path, but some threads might handle multiple paths coming from the same client.
• One additional thread for each asynchronous activate, for the duration of the activate; when finished, the thread disappears.
• One additional thread for each Uniface Server that is being started; it disappears as soon as the Uniface Server is ready to receive requests.

Uniface Router Failure Recovery

If the Uniface Router fails for some reason, it is automatically restarted after 10 seconds.

Note: On iSeries, the Uniface Router is not automatically restarted if it fails.

On Microsoft Windows, the Uniface Router runs as a service that is configured to automatically restart. If it stops again within 60 seconds, it is restarted after 30 seconds. If it crashes a second time in 60 seconds, it is not restarted. To change this behavior, you can edit the properties in the Recovery tab of the Windows Services tool.

On Unix, crash recovery is controlled by a script file urouter.sh which will always restart the Uniface Router. If the Uniface Router fails, the script copies the last three core dumps. For more information, see urouter.sh.