The overall goal for tuning a PAS for OpenEdge instance is to support an ABL application that meets your requirements for concurrent client requests, response times, and resource consumption. Achieving this goal is an iterative process that begins when you develop the ABL application and set the initial defaults for the target deployment environment. You then perform more refined tuning of the OS, CPU, memory, and file system.

The tuning process typically consists of the following steps:

  1. Tuning the PAS for OpenEdge instances.
  2. Tuning the OpenEdge application and any third-party web applications.
  3. Tuning the OpenEdge multi-session agent.

The following is a general set of steps to tune the PAS for OpenEdge instance:

  1. Deploy the OpenEdge web applications that make up your ABL application to the PAS for OpenEdge instance, increasing the JVM metaspace memory until all web applications start successfully.
  2. Determine and set the maximum number of ABL sessions that a single multi-session agent can support based on your ABL application memory allocation of variables, r-code, and buffer space.
  3. Calculate the maximum ABL session pool size where the maximum number of ABL sessions across all multi-session agents is based on the sum of:
    • The estimated maximum number of concurrently bound client application connections.
    • The estimated maximum number of concurrently executing inbound client requests.
  4. Set the maximum number of multi-session agents as (session-pool-size / maximum sessions per multi-session agent) +1. The +1 is for handling abnormal load spikes. Use the OEPROP utility to set the AppServer.SessMgr.maxAgents property.
  5. Set the maximum number of local socket connections (maxConnectionsPerAgent) that a single multi-session agent can have. The goal is to maximize the number of concurrently running client requests that one multi-session agent can process. The CPU resources and the level of I/O switching of the individually executing ABL requests influence the value. This number must be less than or equal to the maximum number of ABL sessions for each agent. Use the OEPROP utility to set the AppServer.SessMgr.maxConnectionsPerAgent property.
  6. Set the idle resource timeouts to lower the resource load on the server without causing multi-session agent or ABL session thrashing. These settings are directly related to how long it takes an ABL session to be started in your ABL application. Use the OEPROP utility to set the AppServer.SessMgr.idleResourceTimeout property.
  7. Set the number of initial ABL sessions an multi-session agent starts when it is created. Keep this number to a minimum because it affects how long it takes for the PAS for OpenEdge instance to become available to handle the client load. The goal is to initialize enough ABL sessions to handle the initial client load, and then to gradually scale up (trading off the initial client response times) until the PAS for OpenEdge instance reaches full capacity. Use the OEPROP utility to set the AppServer.Agent.numInitialSessions property.

Keep in mind that the maximum capacity of a single PAS for OpenEdge instance is finite for any given combination of ABL application and OS hardware. When you reach a single PAS for OpenEdge instance limits within the current environment, and you have not met the performance requirements, you must either increase the OS hardware capacity, or run additional PAS for OpenEdge instances and load balance the instances.

For information about how to scale PAS for OpenEdge instances, see Scaling considerations in PAS for OpenEdge.