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.

• 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 Reviewing requestor pool information and the Admin Studio help.