How should I properly to configure jmeter for high-volume outbound dialer load testing without triggering api rate limits or causing the architect flow to stall?
we are running a proof of concept for an outbound campaign in the us-east-1 region. the goal is to simulate 500 concurrent predictive dialer attempts using the rest api. we are using jmeter 5.6.2 with the http request sampler.
the script calls /api/v2/outbound/campaigns/{campaignId}/preview to initiate calls. when we ramp up to 200 threads, the response time is acceptable (around 200ms). however, at 400 threads, we start seeing 429 too many requests errors. increasing the thread count to 500 results in a mix of 429s and 503 service unavailable errors.
the jmeter configuration uses a constant throughput timer set to 6000 requests per minute. we have enabled keep-alive and connection pooling. the api key used has the full outbound_campaigns_read_write scope.
is there a specific header or parameter we need to add to bypass the default rate limiting for load testing? or is the 429 error expected behavior for this endpoint? we need to understand the true capacity of the outbound dialer before moving to production.
also, does the architect flow handle the disconnect events correctly under this load? we noticed some calls are logged as ‘no answer’ in the activity monitor, but the sip trunk logs show a ‘busy’ status. this discrepancy makes it hard to validate the test results.
any guidance on the best practices for testing outbound dialer performance at scale would be appreciated. we are looking for a stable baseline to compare against different campaign configurations.
thanks in advance.