Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Requestor pooling for services

Updated on August 25, 2021

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 Learning about default dynamic system settings.

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

Configure requestor pools for your service workload scenario by editing the number of idle requestors, active requestors, and wait time (in seconds) relative to their initial configuration. Service requests fail when active requestors completely deplete from the pool and service requests time out, but planned configuration can improve request fulfillment percentages.

Note: When editing requestor pools, never set Maximum idle requestors size higher than Maximum active requestors. Requestors remain unused in idle pool if an idle requestor value exceeds active requestor value.

  • 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 Learning about default dynamic system settings.
    • 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.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us