Context:
running jmeter 5.6 to simulate high volume outbound campaign activity in us1. the goal is to test the capacity of the predictive routing engine when handling rapid succession of call attempts. we are using the /api/v2/outbound/campaigns/{campaignId}/start endpoint to trigger a campaign with a predicted volume of 50 concurrent calls per minute.
the test setup involves a simple architect flow that routes to a single user group with 10 agents. initially, the calls connect successfully. however, after approximately 15 minutes of sustained load, the api responses for new call attempts start returning 503 service unavailable errors. the error message indicates “predictive routing engine overloaded”.
we have verified that the sip trunk capacity is sufficient and that the agents are available. the issue seems to be specific to the predictive dialer’s internal state management or rate limiting on the campaign start api. we are not seeing any 429 too many requests errors, which suggests this is not a standard api rate limit issue.
the jmeter thread group is configured with 50 threads, a ramp-up period of 10 seconds, and a loop count of 10. each iteration waits 2 seconds before triggering the next call attempt. we are using the client credentials grant for authentication and have ensured that the oauth token is refreshed automatically.
Question:
can anyone clarify if there is a known limitation on the number of concurrent predictive calls that can be initiated via the api in a short timeframe? are there specific headers or parameters that need to be included in the request to handle high-volume scenarios better? we are looking for ways to stabilize the load test without hitting the 503 errors. any insights into how genesys cloud manages the predictive routing engine’s load would be helpful. we are open to adjusting our jmeter script or the campaign configuration to better align with the platform’s capacity limits.