Why does this setting cause BYOC edge overload?

Why is this setting causing BYOC edge overload?

We are hitting a wall with our latest stress test.

The goal is to validate concurrent WebSocket connections on a dedicated BYOC edge.

We are using JMeter 5.6.2 to simulate agents.

The script opens wss://api.mypurecloud.com/api/v2/communications/active sessions.

We ramp up to 500 concurrent users over 60 seconds.

The first 200 connections succeed immediately.

Then the error rate spikes to 40%.

The logs show 503 Service Unavailable responses.

The response headers indicate the edge is rejecting new connections.

We checked the Edge health dashboard in Genesys Cloud.

The CPU usage is only at 45%.

Memory usage is stable at 30%.

Network throughput looks normal too.

So the hardware is not the bottleneck.

We suspect an API rate limit issue.

We are using the standard OAuth2 token flow.

Each thread gets a unique agent token.

We are not reusing tokens.

The error happens at the WebSocket handshake stage.

It fails before the upgrade to wss.

We see the 503 error in the JMeter response code column.

We tried adding a constant timer.

We added a 2-second delay between requests.

The error rate dropped but did not disappear.

We still see failures at 400 concurrent users.

We read the documentation on platform limits.

It mentions a global WebSocket limit.

But BYOC edges should have higher capacity.

We are on the Enterprise plan.

We have a dedicated edge cluster.

We want to know if there is a hidden limit.

Is there a max concurrent connection count per edge?

How do we calculate the safe load threshold?

We need to plan for 2k concurrent agents.

Current results suggest we cannot scale past 300.

This is a major blocker for our project.

Any insights on tuning JMeter for this?

Or is this a platform configuration issue?

We are in Singapore timezone.

Tests run during off-peak hours.

No other load on the system.

Please share your JMeter configs if possible.

We want to replicate your success.