TS/MP System Management Manual (G06.24+, H06.03+)

Configuring Objects in a PATHMON Environment
NonStop TS/MP System Management Manual—541819-001
3-26
Understanding the Effects of Link Configuration
NUMSTATIC
The NUMSTATIC attribute specifies the maximum number of static servers within a
server class. Because it is recommended that you run your application with static
servers only, you should specify the same value for NUMSTATIC that you specify for
MAXSERVERS. This way, no dynamic servers should ever be required. If you use
this approach, you can allow the CREATEDELAY and DELETEDELAY attributes to
default, because they apply only to dynamic servers.
The value of MAXSERVERS minus the value of NUMSTATIC equals the number of
dynamic server processes in the server class. Because the default NUMSTATIC value
is zero, failing to supply a value for NUMSTATIC causes all server processes to be
dynamic. A configuration running only dynamic server processes is not recommended
because the PATHMON process does not apply load balancing algorithms to dynamic
server processes. Without load balancing, the first server process that starts up could
be overloaded. Thus, it is recommended that you supply a value for NUMSTATIC.
The maximum number of static links that a link manager, such as the LINKMON
process, can have is determined by the formula NUMSTATIC * LINKDEPTH.
CREATEDELAY and DELETEDELAY
CREATEDELAY is the length of time a send request queues before the link manager
asks for another link, assuming the link manager has determined that no more static
links are available (that is, only dynamic links are available).
A link manager will always ask for a link immediately if the link manager has
determined that static links are still available.
The DELETEDELAY attribute specifies the amount of time that a dynamic server sits
idle before the link manager returns the link to the PATHMON process.
For more information about static and dynamic servers, see Configuring Server
Classes on page 3-16.
Understanding the Effects of Link Configuration
Application performance often depends on how well links between requesters and
server processes are managed. If your application is configured in a way that creates
requester queuing problems or a bottleneck in server process responses, performance
suffers.
Suppose, for example, that you set the server attribute LINKDEPTH equal to 20, which
permits 20 concurrent requests to a server process. If transaction service time is 1
second and the server class handles requests serially, response time might be as
much as 20 seconds. Thus, this LINKDEPTH setting can cause send requests to
queue on the server class for unacceptable lengths of time.
As another example, suppose MAXLINKS is 1 and you also set the server attribute
MAXSERVERS to 1, indicating that only one server process can run in this server
class at a time. If this setting is too low, send requests may queue for the link manager