Stuck on Architect flow timeout during JMeter load test

Stuck on an issue with my architect flow. i am running a jmeter test to simulate high volume inbound calls. the goal is to see how the system handles 200 concurrent sessions hitting a specific ivr path.

the flow is simple. get inbound call → set variable → http request to internal api → switch based on response.

when i run the test with 50 users, everything works fine. the http request node gets a 200 ok in about 200ms. but when i increase the thread count to 150, the http request nodes start failing. i am seeing a timeout error in the architect logs. the error code is TIMEOUT and the duration is exactly 30 seconds.

i checked the api endpoint directly with postman and it responds instantly even under load. so the backend is not the issue. it seems like the architect flow is dropping the request or not sending it properly when the queue builds up.

my jmeter config uses a constant throughput timer. i am setting the rate to 100 transactions per second. the websocket connections for the calls are established successfully. the issue is inside the flow execution.

i tried increasing the timeout setting in the http request node to 60 seconds but it still fails at 30s. i also tried adding a delay node before the http request but that just makes the calls wait longer and then fail.

is there a limit on how many http requests architect can process per minute? the documentation mentions rate limits for the public api but i am not sure if this applies to internal flow executions.

any help would be appreciated. i need to validate the capacity before our go live date. currently the flow fails for 40% of the calls when load exceeds 100 concurrent users. this is a blocker for our performance test.

This seems like a standard timeout configuration mismatch between the Architect HTTP node and the downstream API capacity limits. When scaling to 150 concurrent sessions, the internal API likely cannot process requests fast enough, causing the Architect flow to wait until its default timeout expires.

The default timeout for an HTTP request node in Genesys Cloud Architect is 30 seconds. If your internal API takes longer than this under load, or if the connection pool is exhausted, the node fails. You need to adjust the timeout settings in the HTTP node configuration and ensure the downstream API can handle the burst.

Check the following settings in the HTTP Request node:

• Timeout: Increase from 30s to 60s or higher if the API is slow.
• Retry Policy: Add a retry with exponential backoff to handle transient failures.
• Concurrency: Ensure the API endpoint supports concurrent connections.

If the issue persists, consider adding a queue or buffer before the HTTP request to smooth out the burst. This prevents overwhelming the internal API and reduces the chance of timeouts.

Also, verify that the internal API is not rate-limiting requests. A 429 Too Many Requests response can sometimes be misinterpreted as a timeout if not handled correctly in the flow.

Here is a sample configuration for the HTTP node:

{
 "timeout": 60000,
 "retries": 3,
 "retryDelay": 1000
}

This approach ensures that the flow can handle higher concurrency without failing due to temporary delays. Adjust the timeout based on the actual response time of your internal API under load.