Web application startup parameters

Startup time and initial client request handling

When a PAS for OpenEdge instance is started, the session manager must start at least one multi-session agent. During the startup of a multi-session agent, the session manager holds until the multi-session 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 multi-session agent either unresponsive or unable to start.

The session manager uses the numInitialAgents property to begin building a list of multi-session agent processes. The multi-session agent process uses the numInitialSessions property at startup time to begin building the list of physical ABL sessions. For example: 1 multi-session agent with 5 initial ABL sessions yields an initial ABL session pool size of 5. Starting 3 multi-session agents with 5 initial ABL sessions each, yields an initial ABL session pool size of 15.

Tuning tips:

• The longer the time the agentListenerTimeout property is set, the longer the PAS for OpenEdge instance takes to start if the multi-session agent process has startup failures. If the agentListenerTimeout property is set to too short of a time, then the PAS for OpenEdge instance may start sooner, but the session manager may consider the multi-session agent unavailable.
• Setting the number of multi-session agent processes and physical ABL sessions to start at initialization time depends on how long the ABL application implementation takes to run its startup procedure. A larger number causes the PAS for OpenEdge instance to not handle incoming client requests for a longer period of time. A smaller number causes client requests handled by PAS for OpenEdge to have slow response times when new ABL sessions, or multi-session agent processes, or both are started.

Multi-session agent parameters and ABL sessions

After the 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 multi-session 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 multi-session 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 multi-session 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 multi-session agents as small as possible by maximizing the number of ABL sessions and concurrent client requests for each multi-session agent.
• The more multi-session 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 multi-session agent and a few ABL sessions.
• Scaling to handle more multi-session agent processes is normal when the ABL application supports stateful client requests. The overhead for stateful clients is low because they are directly dispatched for execution to an exact ABL session within an exact multi-session agent, without the need to find an idle ABL session.

As stated previously, the goal of the session manager is to conserve resources. It does this by periodically searching for multi-session agent and client sessions that are idle in excess of the idleAgentTimeout and idleSessionTimeout periods, respectively. When an idle multi-session 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 non-peak hours, then this may lead to thrashing, causing client response times decrease because multi-session 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 multi-session agent and ABL session startups and idle resource shutdowns occur, then increase the time they can remain idle before being harvested.
• You also have the option of manually controlling the harvesting of idle multi-session agents and ABL sessions. To disable the automatic idle resource harvesting, set the idleResourceTimeout property to 0, and use the JMX or remote OpenEdge administration plugin to manually harvest the idle resources.

Manage concurrent request execution

A multi-session agent can 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 multi-session 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 multi-session 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 multi-session 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, then increase the number of socket connections and ABL sessions because many of them will have high idle times, then the CPU resources can be used for executing CPU-bound ABL language statements.