Script Performance

Factors that influence the speed/efficiency of your scripts

With no restriction on the size, number or complexity of scripts, the performance of each script will vary according to the individual script logic and the various paths/flow taken. In general, this is not a problem however if there is any doubt as to the performance of any new script logic then a test is always advisable before a live script update.

The guidelines below should help to identify characteristics in a script that may indicate the need for caution.

Overall System Performance

In the event of a noticeable reduction in performance, you should first consider if there have been any script (or other known) changes that could be causing the problem. In general, ‘normal’ day to day script changes would not cause a problem however it would be worthwhile carefully checking any Startup and Results System scripts changes, try to pinpoint any bottlenecks and reversing the changes if required. If script changes have been eliminated as a cause then an issue should be raised with your local IT support. They should check for known system changes that may have introduced the problem, any additional workload on the system or general problems on the application or database servers themselves. Regardless of specific script logic, overall performance is heavily reliant on the underlying infrastructure.

Startup and Results System scripts

Clearly these scripts will run with every request and any excessive processing will be exaggerated with more operators using the system. The general guidelines should be followed as with any script.

SQL Databoxes

Check connections to external databases with the SQL Databox Test button; connection issues can cause significant delays and invalid SQL can cause problems on the database server. The operation of the SQL query itself should be carefully considered as there are a plethora of factors that can influence the performance/efficiency/accuracy of results. This includes an appreciation of the underlying schema, awareness of indexes, minimising locking risk and confirming expected results are returned etc. In general, the SQL query should access data by specific key values, not lock the data and not return large volumes of data. Full guidance as to how to construct efficient SQL queries is beyond the scope of the Keyfax documentation. If in doubt, please consult your local database administrator or request additional assistance from Omfax.

All Databoxes are re-evaluated each time they are referenced either directly or through an expression; for SQL Databoxes this will re-run the SQL query and could be inefficient. If it is known the query will always return the same result and the query returns multiple values or is referenced several times in the script then it is better to use a Databox-Write to store the original result into a separate Script Databox and use the latter for all subsequent references.

Script Size

The number of Script Sets, Categories, Topics and even the length of scripts does not affect performance. The significant factor is the number of script steps executed in any one path through the script. Typically, scripts will not prompt the operator with too many questions and messages or export large numbers of SORs and tasks. Otherwise, script steps control the script logic by processing Databoxs and expressions. There is no fixed point at which this will noticeably affect performance; as a rule of thumb, script paths in excess of 50 ‘logic’ steps are starting to become excessive. Some sites are running live scripts OK with over 100 ‘logic’ steps however this is not recommended. In general scripts processing more than 50 ‘logic’ steps in any script path will probably be cumbersome and difficult to maintain. Anyone contemplating writing such scripts should check with Omfax to review the logic.