Optimizing Actions - EcoSys - Help - Hexagon

EcoSys Performance Tuning

Language
English
Product
EcoSys
Search by Category
Help
EcoSys Version
9.2

Optimizing Load Time in Actions

Regarding custom fields, assigned categories, assigned tasks, costs/units, formulas and related objects: each of these fields incur extra overhead each time one is added to your action. Therefore, to make sure your action is running as fast as it possibly can, you want to make sure you are including only the fields you need in the action.

Update Actions

When running an update action, the only fields you need are fields that …

  1. have a row filter defined.

  2. are used in the update logic (either as a source or a target value).

  3. are needed to create the necessary granularity of summarization (transaction summary subject area only).

Any fields that do not serve one or more of the above purposes should be removed from your update action.

Delete Actions

When running a delete action, the only fields you need are fields that have a row filter defined. No other fields are necessary.

Copy Actions

When running a copy action, the only fields you need are fields tht:

  • Have a row filter defined.

  • are used in the update logic (either as a source or a target).

  • are needed to create the necessary granularity of summarization (transaction summary subject area only).

  • are custom fields, assigned categories, assigned tasks or cost/unit values that you want copied to the new records.

Any fields that do not serve one or more of the above purposes should be removed from your create action.

High Performance Actions

One common use for actions is to copy and/or move a bulk of transactions from one version to another. This is typically done when archiving or base lining a set of data. When you need to copy/move transactions to another version, there are two actions that are optimized to accomplish this task much faster than a regular Copy or Update action.

Copy To Version / Move To Version Actions

These actions are similar to update actions in that you may add columns necessary to row filter you data down to the set for which you wish to move/copy to another version. However, instead of configuring update logic to transform the data, on the Update Logic tab, you simply specify the target version.

By default, the Copy/Move To Version actions will NOT recalculate your cost values. So, if changing the version would impact the exchange rates being used, you should select the “Recalculate currency costs” option on the Update Logic Tab.

Transaction Summary VS Transaction Actions

Please keep in mind that better performance can be achieved with Transaction Actions instead of using Transaction Summary. Transaction Summary (TSUM) actions should only be used when not possible or practical to use Transaction Actions as Transaction Actions scan less levels of data to produce required results.

Applying Custom PULS (Parallel Load/Save) Settings

A given spreadsheet, report, or action can be configured to use a customized number of parallel threads, independent of the system-wide defaults. This feature within the PULS functionality is useful for special cases that may benefit from additional resources, or when you want a given request to use less resources than the default. These settings should be used carefully and validated using benchmark tests before they are employed widely or by end users, since they can have other implications for system resources. See the section on configuring PULS values system-wide for additional details.

Number of Threads to Load Data

You can override the system-wide default number of threads for loading data using the Options > Advanced section of the dictionary in question. Note that even if this value exceeds the system-wide maximum value, only the system-wide maximum number of threads will be applied, as a given user cannot override this. For spreadsheets/reports/actions that contain a large volume of cost/unit fields and/or formulas with cost/unit fields, you may gain better performance as you increase the number of threads used to load data. The optimal ratio of threads to cost/unit columns should be about 1:3. However, some experimentation is recommended because other factors can cause differences in performance as you increase the number of threads used to load data.

Number of Threads to Save Data

You can override the system-wide default number of threads for saving data using the Options > Advanced section of the dictionary in question. Note that even if this value exceeds the system-wide maximum value, only the system-wide maximum number of threads will be applied, as a given user cannot override this. For spreadsheets/actions that save a large number of rows, you may see better performance as you increase the number of threads used to save data. The optimal ratio of threads to number of rows to save should be about 1:100. However, some experimentation is recommended because other factors can cause differences in performance as you increase the number of threads used to save data.

Reducing Data Volume

Response time is often directly correlated to number of rows and columns processed. For spreadsheets, actions, and reports, reducing the number of rows and columns involved can speed them up. Related considerations for improving performance include:

  1. Consider altering the user’s workflow so that less data is viewed or edited at once.

  2. Provide more options for run time parameters that filter the data so that the user may select only the data they want to work with, rather than viewing or editing a larger dataset. Marking filter run time parameters as required will prevent loading datasets without filters.

  3. In the browser, performance is often improved by lowering the number of rows displayed on each page. Even with a large dataset from the server, showing smaller pages of it at a time will let the screen refresh faster. This is typically a training issue since display page size is in the hands of the end user.