Looking for advice on Architect flow dropping calls during JMeter load test

Architect & Flows
1

Looking for advice on how to handle high concurrency in Architect when using JMeter for performance validation. The environment is Genesys Cloud version 2024-12. My current setup involves a simple IVR flow that routes to a queue with 50 agents online.

When the JMeter script ramps up to 200 concurrent threads, the system starts rejecting incoming SIP INVITEs. The specific error observed in the debug logs is “486 Busy Here” returned by the edge server. This happens even though the queue capacity is not reached. The WebSocket connections seem stable, but the call setup fails.

Environment details:

  • JMeter version: 5.6.2
  • Thread count: 200 concurrent
  • Ramp-up period: 0 seconds (instant start)
  • Architect flow: Single queue node with standard timeout settings
  • Genesys Cloud version: 2024-12

Is there a configuration limit on the Architect side that caps the number of simultaneous flow executions? The documentation mentions API rate limits, but this appears to be a media path issue. The SIP trunk provider confirms they are sending the calls correctly. I suspect the Genesys Cloud edge might be throttling the call setup requests before they reach the flow logic. Any insights on how to tune the flow or increase the concurrency limit for testing purposes would be helpful.

2

The 486 Busy Here error usually means the SIP trunk or edge capacity is saturated, not the queue logic. Check if your JMeter script is reusing SIP UA instances or if you are hitting the WebSocket connection limit on the platform_api side.

Try reducing the concurrent thread count in JMeter to match your outbound call capacity per edge. The platform_api rate limits can also cascade into SIP failures if the signaling load exceeds the WebSocket threshold.

3

Make sure you validate the architectural constraints before attributing failures solely to SIP edge saturation. The 486 response often indicates that the flow logic itself is hitting concurrency limits or resource locks, rather than just network bandwidth issues. While the previous suggestion regarding SIP UA reuse is technically sound for network-side debugging, the Architect configuration must also support the load. Specifically, check if your IVR flow contains any blocks with strict concurrency limits or long-running asynchronous tasks that might block thread execution.

The following payload structure should be reviewed in your JMeter script to ensure proper header handling during high-volume tests:

{
 "method": "POST",
 "url": "/api/v2/flow/outbound",
 "headers": {
 "Content-Type": "application/json",
 "Authorization": "Bearer <token>"
 },
 "body": {
 "campaignId": "your_campaign_id",
 "contactId": "unique_contact_id"
 }
}

Adjusting the request rate to align with platform capacity thresholds typically resolves these intermittent drop-offs.

4

Have you tried aligning the JMeter load with the concurrency_limits defined in the WFM schedule group? Predictive capacity is strictly tied to those settings. Even if the edge handles the SIP load, the platform rejects calls if the schedule group isn’t configured to support that volume.