Requestor pooling for services
A requestor pool is a set of requestors that are reserved for use by the services in a specific service package. Requestor pooling often improves the performance of a service because requestors are reused, their allocated resources are shared, and the service need not wait for a requestor to be created.
To enable requestor pools, see Dynamic system settings data instances.
To edit requestor pool sizes, see Service Package form – Completing the Pooling tab.
Requestor pools must be enabled to access. To access the Requestor Pools landing page, view the list of requestor pools, view details about a requestor pool, and open a service package form, you must have the PegaRULES:SysOpsObserver role. To perform all available actions on requestor pools, for example, to clear a requestor pool, you must also have the PegaRULES:SysOpsAdministrator role.
How it works
The first time a service from the service package runs, a requestor is created for it along with the pool for the service package. When the service processing is complete, the requestor is added to the pool.
The next time a service from that service package runs, the service is assigned a requestor from the pool if one is available. Otherwise, a new requestor is created and assigned. When the service completes, the requestor returns to the pool.
Requestors associated with a pool belong in one of two categories:
- Idle requestors are currently in the pool, waiting for a service request.
- Active requestors are currently out of the pool, managing service requests.
You specify how many requestors can be in the pool on the Pooling tab of the service package form. The setting for the number of idle requestors defines the size of the pool. The setting for the number of active requestors defines how many concurrent requestors you want to allocate to the services in the service package.
When the pool does not have idle requestors, new requestors are created for service requests until the limit specified for active requestors is reached. If a service request arrives after the limit is reached and no idle requestors are in the pool, the request is managed after an active requestor returns to the idle requestor pool.
When an active requestor completes processing, the limit for idle requestors is checked before returning that requestor to the pool. If the pool is under the limit, the requestor becomes idle and returns to the pool. If the pool is at the limit, the requestor is deleted instead.
Best practice for configuring requestor pools
- Time interval between each service request (request frequency):
- For fluctuating service requests, increase the number of Maximum active requestors significantly higher than Maximum idle requestors.
- For service requests with consistently short intervals, decrease the number of Maximum idle requestors.
- For service requests with consistently long intervals, increase the number of Maximum idle requestors.
- Time interval between request and subsequent response:
- When interval is consistently short, decrease the Maximum wait (in seconds).
- When interval is consistently long, increase the Maximum wait (in seconds).
- Overall service reliability:
- When the required service reliability requires a higher success percentage, increase the Maximum wait (in seconds).
- Response time reliability:
- When response time reliability (measured as high request frequency with short response time) requires a higher success percentage, increase the number of Maximum idle requestors.
- In Client-managed cloud deployments, requestor pools are disabled by default. When
Client-managed cloud deployments require a higher service response time than the
elastic-provisioning output delivers, or when all component nodes of the environment
utilize unauthenticated and stateless service packages, complete the following:
- Enable requestor pools on your environment. To enable requestor pools, see Dynamic system settings data instances.
- Increase the number of both Maximum Idle Requestors and Maximum Active Requestors.
- Decrease the Maximum wait (in seconds).
Reviewing requestor pool information
When monitoring a service, use Admin Studio to examine the status of the requestor pools. For more information, see Managing requestor pools and the Admin Studio help.