Architect Script Node Timeout during JMeter Spike Test

TimeoutException: Script execution exceeded 3000ms limit

Running a load test with 50 concurrent WebSocket connections using JMeter 5.6.2. The goal is to simulate a sudden influx of calls hitting a specific Architect flow that uses a Script node for dynamic greeting generation based on caller ID.

The flow works fine with 10 concurrent users. At 50, the Script node starts timing out consistently. The script is simple JS, just fetching a variable and returning a string. No external API calls inside the script.

“Script nodes have a strict execution time limit to prevent blocking the flow engine. Complex logic should be offloaded to external services.”

I know it’s a limit, but 3 seconds seems short for basic string manipulation under load. Is there a way to increase this limit via API? Or is this a hard cap in the platform? The error occurs on POST /api/v2/architect/flows.

JMeter config:

  • Thread Group: 50 users
  • Ramp-up: 0s
  • Loop: Infinite
  • Protocol: WSS (WebSockets)

Any tips on optimizing the script or handling this at scale? The latency spikes are killing our throughput metrics.

If I remember right, the 3000ms limit is hard-coded for Architect script nodes and cannot be extended via configuration. When running high-concurrency load tests like this JMeter spike, the platform’s shared compute resources for script execution become saturated, leading to queue delays that exceed the timeout threshold. This is distinct from network latency or backend API failures.

The documentation suggests that complex logic or high-volume concurrent script executions are prone to this specific failure mode. For legal discovery or bulk data processing, we typically avoid embedding heavy logic in real-time flow scripts. Instead, consider moving the dynamic greeting generation to a pre-processing step or using a simpler lookup table if possible. If the script is unavoidable, ensure it is as lightweight as possible-avoid any external HTTP calls or heavy string manipulation within the node. The timeout is a protection mechanism against resource exhaustion, not a bug in the script logic itself.