Settings for Concurrent Provisioning Request/Response

The settings for Concurrent Provisioning Request/Response allows you to tune the performance parameters to scale up the processing request/response rates for PP and PR containers.

How PEM Portal activity initiates Partner Provisioner (PP) activities and updates configuration status in Partner Repository (PR)

Provisioning of a partner configuration is initiated from PEM Portal activity by using a REST API. The REST API modifies the configuration status in PEM PR and adds a provisioning request in a JMS 'request' queue that PEM PP listens to. PP picks up a provisioning request from the queue and starts the provisioning process as per the defined topologies and provisioning rules. When the process is complete, PP sends a provisioning response in another JMS 'response' queue that PEM PR listens to. PR picks up the provisioning response from the queue and modifies the configuration status depending on the status provided by PP. Then, it sends a trigger to PEM Portal to unlock the waiting activity.

Limitation on PP and PR’s concurrent request/response processing rate

Irrespective of the number of provisioning requests initiated through the REST APIs through the onboarding activities in PEM Portal, both PR and PP have an upper limit on the number of provisioning requests and responses they can concurrently handle. Between the two, PP takes the maximum time, which can be up to a few minutes, to complete processing of a provisioning request. This duration varies with the number of REST APIs invoked from PP activities and the response time of each API. However, in comparison, PR takes only few seconds to complete the processing of a provisioning response as it only performs two tasks - update the configuration status and unlock the PEM Portal activity.

For example, if PP takes 60 seconds to complete processing one provisioning request, PR only takes 2 seconds to complete processing one provisioning response. Thus, PR can process 300 responses in the same time it will take PP to complete processing 10 requests.

Tuning PP and PR’s concurrent request/response processing rate

Option 1

The servers.provisioner_request_listener_max_concurrency property in Setup.cfg allows scaling up the concurrent request processing rate for a PP container. The recommended maximum provisioning limit for a container is 100. The default value is 10.

The servers.provisioner_response_listener_max_concurrency property in Setup.cfg allows scaling up the concurrent response processing rate for a PR container. The recommended maximum provisioning limit for a container is 100. The default value is 10.

For example, By default 1 PP container can process up to 10 provisioning requests concurrently. If we have set property as servers.provisioner_request_listener_max_concurrency=100, PP container can process up to 100 provisioning request concurrently. In this case, the 101st request will wait in the queue until PP completes processing of one of the initial 100 requests. Similarly, 1 PR container can process up to 10 provisioning responses concurrently by default. If we have set property as servers.provisioner_request_listener_max_concurrency=100, PR container can process up to 100 provisioning request concurrently.

Note: Increasing the number of concurrent listeners have the potential to increase the resource utilization (memory, CPU, etc.) of PR and PP containers. You must perform load testing in your environment to determine the right property value for your deployment.

Option 2

Deploying additional PP containers is another way to achieve the desired processing rate for concurrent provisioning requests in PP. Additional PR containers must be deployed to handle the increase in API calls from the additional PP containers.

Note: Load testing must be performed in the customer’s environment to determine the appropriate number of PR containers required.

For example, 10 PP containers can process up to 100 provisioning requests concurrently. In this case, the 101st request will wait in the queue until PP completes processing of one of the initial 100 requests. Similarly, 10 PR containers can process up to 100 provisioning responses concurrently. However, since PR takes a significantly shorter time to process responses, the number of PR containers can be reduced if a delay of a few seconds can be tolerated.