Our UCCX servers often hit memory thresholds, and I'm wondering if our scripting topology could be the problem.
Do you mean the Java heap limit or something else? The heap is fixed at 256MB and hitting it triggers an automatic dump which will drop all calls.
As for the pros of splitting the scripts, the most common reason is for reporting purposes. CCX lacks any report that shows which IVR options a caller pressed (e.g. how many pressed 1 for sales, 2 for tech support). Many have compensated for this by doing redirects to other triggers, for which there is an application-level report that shows call counts per-trigger.
The con of this is that it will drag down system capacity due to the increase CTI traffic per-call as it gets redirected from app to app to human. Another possible con is that every script has to be loaded into the Java heap for runtime execution. How much memory you save by one big script vs. many small ones isn't known though.
On a related note, all of the variables get loaded into memory for every contact being executed and remain in memory until the session expires (30 minutes after the call is finished by default). So, one way to conserve memory is not to create a variable for every possible thing. Many people consider building a variable for every prompt, transfer-to destination, etc. a best practice. It isn't and I only create a variable if it needs to be a parameter or something actually needs to store/retrieve data. I also use reusable variables such as "cacheStringA" when I only need data between two steps such as a Get Reporting Statistic step and the subsequent IF step. Why have a permanent dedicated variable?
Please remember to rate helpful responses and identify helpful or correct answers.
