Web application startup parameters

The following topic explains how to control PAS for OpenEdge startup times, ABL sessions for executing client requests, and concurrent client request execution.

Startup time and initial client request handling

When a PAS for OpenEdge instance is started, the Session Manager must start at least one MS Agent. During the startup of a MS Agent, the Session Manager holds until the MS Agent gets a callback connection from the Session Manager to report its startup status and any subsequent notifications. The Session Manager holds for a agentListenerTimeout period before it considers the MS Agent either unresponsive or unable to start.

The Session Manager uses the numInitialAgents property to begin building a list of MS Agent processes. The MS Agent process uses the numInitialSessions property at startup time to begin building the list of physical ABL sessions. For example: 1 MS Agent with 5 initial ABL sessions yields an initial ABL session pool size of 5. Starting 3 MS Agents with 5 initial ABL sessions each yields an initial ABL session pool size of 15.

Tuning tips:

• The longer time the agentListenerTimeout property is set, the longer the PAS for OpenEdge instance takes to start if the MS Agent process has startup failures. Too short of a time, and the PAS for OpenEdge instance may start sooner but the Session Manager may consider the MS Agent unavailable.
• Setting the number of MS Agent processes and physical ABL sessions to start at initialization time is dependent on how long the ABL application implementation takes to run its startup procedure. A larger number takes more time, which causes the PAS for OpenEdge instance to not handle incoming client requests for a longer period of time. A smaller number and the first client requests handled by PAS for OpenEdge will have slow response times while new ABL sessions or MS Agent processes, or both, are started.

MS Agent parameters and ABL sessions

After initial startup the Session Manager automatically scales the number of ABL sessions according to the client load. Session Manager scaling begins with adding ABL sessions to the first MS Agent process until its maxABLSessionsPerAgent limit is reached. If additional ABL sessions are required to meet client demand, then the number of physical ABL sessions is scaled up in the next MS Agent process until its maxABLSessionsPerAgent limit is reached. This scaling process continues until the maxAgents limit is met, when the Session Manager begins to return no session available errors to its clients.

Tuning tips:

• The setting of the MS Agent maximum ABL sessions property is related to the OS process memory or file limits. Each ABL session that runs your ABL application code consumes memory and other process resources. Therefore, do not set the maximum ABL sessions to a number greater than what the OS process can support.
• The best performance is obtained by keeping the number of MS Agents as small as possible by maximizing the number of ABL sessions and concurrent client requests for each MS Agent.
• The more MS Agents that are started, the higher the overhead in dispatching incoming stateless client requests for execution. The ideal case for stateless ABL application models is one MS Agent and a few ABL sessions.
• Scaling to handle more MS Agent processes is normal when the ABL application supports stateful client requests. Overhead for stateful clients is low because they are directly dispatched for execution to an exact ABL session within an exact MS Agent, without the need to find an idle ABL session.

As stated previously, the Session Manager goal is to conserve resources. It does this by periodically searching for MS Agent and client sessions that have been idle in excess of the idleAgentTimeout and idleSessionTimeout periods respectively. When an idle MS Agent or client session exceeds the idle time, it is removed from service and is shut down gracefully.

Tuning tips:

• If your client traffic has frequent peaks and valleys, this may lead to thrashing whereby client response times decrease because MS Agents and ABL sessions are harvested too soon and the client must wait for new ones to be started.
• If the OpenEdge metrics indicate that too many MS Agent and ABL session startups and idle resource shutdowns occur, increase the time they can remain idle before being harvested.
• You also have the option of manually controlling the harvesting of idle MS Agents and ABL sessions. To disable the automatic idle resource harvesting, configure the idleResourceTimeout property to 0 and use the JMX or remote OpenEdge administration plugin to manually harvest idle resources.

Manage concurrent request execution

An MS Agent can only concurrently execute as many client requests as it has socket connections between the Session Manager and itself. The Session Manager automatically scales the number of local socket connections to MS Agents up to the maxConnectionsPerAgent limit while looking for a free ABL session to execute a client request. A result of managing the number of local socket connections is the MS Agent management of its pool of OS threads reserved for executing client requests. Each time a new local socket connection is created, a new OS thread is started to execute client requests arriving through that socket. Each time a local socket connection is closed, an OS thread from the pool is stopped. When a local socket connection is created and an OS thread exists to execute client requests, it can be used by any client request regardless of the bound-client state.

Tuning tips:

• Do not set the maxConnectionsPerAgent value to be greater than the value for maxABLSessionsPerAgent.
• Do not set the sum of local socket connections for all MS Agents to be greater than the PAS for OpenEdge thread pool for executing HTTP requests, because they will never be used.
• Choosing an appropriate number of local socket connections is closely tied to the implementation of the ABL application. If the ABL application uses high levels of file, database, and socket I/O, you need to increase the number of socket connections and ABL sessions because many of them will have high idle times whereby CPU resources can be used for executing CPU-bound ABL language statements.