Data Action timeout when testing bulk insert via JMeter on Genesys Cloud

NICE CXone API & Integrations
1

Need some help troubleshooting…

  • We are running a load test against the Genesys Cloud Data Actions API to validate our integration pipeline’s ability to handle high-volume concurrent writes. The goal is to simulate a spike in interaction data ingestion during peak hours.
  • The test setup involves JMeter 5.4.1 with a thread group configured for 100 concurrent users, ramping up over 60 seconds. Each thread sends a POST request to /api/v2/dataactions/{dataActionId}/invoke with a JSON payload containing 50 records.
  • The environment is US1, and we are using a standard org license. The Data Action is configured to write to a custom object in Genesys Cloud, not an external database.
  • During the test, we observe a significant drop in throughput after the first 50 requests. The majority of subsequent requests fail with a 504 Gateway Timeout error. The response headers do not provide a Retry-After value, which makes it difficult to implement a robust retry strategy in our JMeter script.
  • We have checked the Data Action logs in the Genesys Cloud admin console, and they show successful invocations for the requests that did not timeout. However, the requests that failed with 504 are not logged, suggesting they might be dropping at the edge or during the initial handshake.
  • We have tried adjusting the JMeter HTTP Request sampler’s timeout settings, increasing both the connect timeout and the response timeout to 30000ms, but the issue persists.
  • We are also checking the WebSocket connection limits, as mentioned in previous threads, but this is a REST API call, so we are not sure if WebSocket pooling applies here.
  • Could someone clarify if there is a specific rate limit or concurrency threshold for Data Action invocations that we are hitting? We are aware of the general API rate limits, but Data Actions seem to behave differently under load.
  • Any insights on how to configure JMeter to better handle these timeouts or if there is a known issue with Data Actions under high concurrency would be greatly appreciated. We are looking to optimize our load test to accurately reflect production traffic patterns without hitting these artificial limits.