Can’t quite understand why the predictive routing API returns 429 errors when JMeter hits 10,000 concurrent WebSocket connections from Singapore.
- Environment: Genesys Cloud (GC) US-East Region
- Tool: JMeter 5.6 with custom WebSocket plugin
- Location: Singapore (Asia/Singapore timezone)
- API Version: platform_api v2
- Load Pattern: 10k concurrent WebSocket connections, 500 requests/sec to /api/v2/predictiverouting/contacts
The queue depth in Architect shows zero, but the platform_api keeps rejecting requests with 429 Too Many Requests. This happens even when the call capacity is well below the configured limit. The error response includes a Retry-After header, but increasing the delay doesn’t help because the rate limit seems to be applied per IP or per tenant, not per user.
JMeter Config:
- Thread Group: 10,000 threads, 0 ramp-up, 1000 loop count
- WebSocket Sampler: Connected to wss://websockets.us-east-1.my.genesiscloud.com
- HTTP Request: POST /api/v2/predictiverouting/contacts with JSON payload
- Timer: Constant Timer, 200ms delay
The issue started after increasing the concurrent connections from 5,000 to 10,000. At 5,000, the API handles the load fine. At 10,000, 429 errors spike to 30% of all requests. The error rate drops back to 0% when reducing to 5,000 threads.
Is there a hidden rate limit for WebSocket connections or API calls per tenant? The documentation mentions API rate limits but doesn’t specify if they apply to WebSocket connections. Also, the Retry-After header suggests backing off, but the load test requires sustained throughput.
Looking for insights on:
- How to bypass or increase the rate limit for load testing.
- Whether the 429 errors are due to WebSocket connection limits or API call limits.
- Best practices for simulating high-volume predictive routing with JMeter.
Any help would be appreciated. The goal is to validate the platform’s capacity before deploying to production.