Context:
Running concurrent load tests against Genesys Cloud Platform API v2 using JMeter 5.5. Ramping to 200 threads triggers immediate 1006 WebSocket disconnects. Environment is standard US-East tenant. No custom rate limit configs visible in admin UI.
Question:
Is it possible to configure higher concurrent connection thresholds for load testing purposes without triggering tenant-level throttling? Current JMeter setup uses standard WebSocket samplers. Need guidance on valid payload structures for capacity validation.
How I usually solve this is by adjusting the keep-alive intervals in the JMeter WebSocket Sampler configuration rather than trying to override tenant-level limits. The default timeout is often too aggressive for cross-region latency, especially when running tests from Asia/Singapore to US-East. Setting the Ping Interval to 30 seconds and the Ping Timeout to 10 seconds helps maintain the connection without triggering the platform’s idle disconnect logic.
“WebSocket connection closed abnormally [1006]”
This error typically indicates the server terminated the connection due to inactivity or resource constraints. You should also verify that your test script isn’t generating excessive metadata payloads that could hit the WebSocket message size limits. If you are simulating high concurrency, ensure the Connection: Upgrade header is correctly set in the HTTP Request Defaults. A common fix is to implement a small delay between thread initialization to avoid overwhelming the initial handshake capacity. Check the actual source IP in the S3 access logs if you are also exporting results, as egress restrictions can sometimes compound connectivity issues during heavy load testing.