I am currently managing a large-scale migration from PureConnect to Genesys Cloud. We are seeing significant performance issues with our custom Data Actions that were migrated from our old ‘Handler’ logic. Specifically, the Data Actions are taking more than five seconds to return a response during our peak traffic windows, which is causing timeouts in our Architect flows. How can we optimize these Data Actions to match the sub-second performance we had on our on-premise handlers?
Hello Val74. I am a predictive routing tester and I have seen these timeouts break our AI models. The problem is likely the ‘API Round-Trip’ time. In PureConnect, your handlers were talking directly to your local database. In Genesys Cloud, every Data Action has to travel over the public internet. You should implement a ‘Caching’ layer (like Redis) in front of your legacy database to reduce the latency for common queries.
I have seen this exact problem during our performance tests. Val74, you should also check the ‘Concurrency’ limits on your Data Action credentials. If you are using a single set of credentials for all your flows, you might be hitting the platform’s concurrent request limit. You should split your Data Actions across multiple credential objects to increase your throughput.
I have been reporting some performance bugs related to Data Action execution history. To follow up on Sat60, make sure you are not using the ‘Test’ mode for your production traffic. The test mode has much lower rate limits and more overhead. Also, use the ‘Velocity’ macros to filter your response payloads on the Genesys Cloud side so you are only returning the absolute minimum data required for your flow. This reduces the serialization time and helps with the overall performance.