Running a JMeter script to validate BYOC (Bring Your Own Cloud) edge performance on Genesys Cloud EU-West. The goal is to simulate 500 concurrent SIP registrations and subsequent media sessions through a custom BYOC trunk. The environment uses Genesys Cloud version 24.1.0 with a dedicated BYOC edge instance.
The issue occurs during the registration phase. When JMeter hits approximately 150 concurrent REGISTER requests, the response time spikes from 200ms to over 5 seconds. Eventually, the edge returns 408 Request Timeout errors for new registration attempts. The media path is not yet established, so this seems to be a signaling capacity limit on the edge itself.
The JMeter config uses HTTP Sampler to send SIP-over-HTTP requests to the BYOC edge endpoint. The headers include standard SIP fields and the Authorization header with a static username/password for testing. No OAuth is used for the SIP trunk authentication in this test scenario.
Has anyone seen similar 408 timeouts during high-concurrency SIP registration on BYOC edges? Is there a known limit for concurrent REGISTER requests per edge instance? The documentation mentions general capacity planning but does not specify the exact threshold for signaling storms.
Also, checking the Genesys Cloud Admin UI, the edge health status remains green throughout the test. No alarms are triggered. The logs show successful registration for the first 150 calls, but subsequent requests are dropped or timed out. The error logs on the BYOC side do not show any specific error codes, just a lack of response from the Genesys Cloud platform.
Trying to determine if this is a configuration issue on the BYOC side or a platform-level rate limit. Any insights on how to tune the edge for higher signaling concurrency? Or is there a recommended way to stagger SIP registrations in JMeter to avoid triggering these timeouts? The current approach uses a simple ramp-up period of 60 seconds for 500 users.