Building performance into applications and workflow

Performance is affected by workflow and application design, as well as by hardware, memory, and other system components. In general, the following guidelines will help you enhance performance of applications:

• Eliminate unnecessary fields.
• Assign field permissions only as needed.
• Minimize the database length of character fields.
• Minimize the number of views.

BMC Remedy Developer Studio provides the ability to view and analyze relationships between objects. For information about these features, see Viewing and sorting related objects and Using Analyzer to find problems in your applications. Active links execute locally, so they typically do not affect the server as much as filters can. In many cases, an active link might be a better choice than a filter. The exceptions are Set Fields actions and Push Fields actions, which should be performed in filters whenever possible.

You should also limit the number of active links for a given form, because too much background activity can slow the workflow.

To improve active link performance, simplify the qualification for active links and combine active links that use the same qualification. This is more efficient than designing two active links that are identical except for their Execute On selection. For example, you might want your users to have the option of clicking a button or pressing Return to open a selection menu list. Design both of these Execute On actions in the same active link. To improve filter performance, simplify the qualification and combine filters that use the same qualification.

Use the filter log to identify when filters are run and the actions the filters take. Consider using workflow logging to test filters from a single user. This will show all activities triggered by the user's transactions. Turn off these logs after analysis, because logs occupy disk space and can slow system performance.

By analyzing these log files, you might discover that active links would be better suited for some tasks. The one situation where filters are often more appropriate than active links is for Set Fields and Push Fields actions. One filter process that consumes large amounts of server memory and CPU processing time is the Run Process-Run Macro operation. If these operations are a part of your primary workflow, consider the resources required to run these processes. Also consider that these processes run in parallel on the server. If several users run these operations simultaneously, system performance slows. Use alternative methods such as Push Fields, custom API programs, or the Filter API.

The following guidelines will help you design efficient escalations:

• Use the minimum number of escalations required for your workflow.
• Run escalations with qualifications that make use of indexed fields whenever possible. For more information about indexed fields, see Indexing specific fields.
• Streamline your escalations by including all available criteria in the qualification. Unqualified escalations run against every record for the form, and might process some records unnecessarily.
• Avoid running escalations during peak user load times.
• Stagger long-running escalations in different pools to avoid overloading the system.
• Avoid running conflicting escalations (those that operate on the same set of data) in different pools at the same time.
• Allow escalations the time they need to complete before the next escalation activates. An example is an escalation that searches the database for 30,000 requests but is set to execute every minute. Escalations are processed in sequence, and an escalation will not run until the escalation scheduled immediately prior to its runtime has completed.

Use the escalation log to identify the times escalations run, how long they take to complete, and the types of actions your escalations perform. Remember that an escalation can modify a request. You can help maintain system performance by minimizing the impact of blocking operations. A blocking operation is an action performed during filter processing that waits for a DBMS or an external process to return the requested information. Blocking operations are caused by Set Fields filter actions, Push Fields filter actions, and $PROCESS$ actions that retrieve information from a DBMS or an external process.

Blocking operations should be avoided whenever possible because they can affect all users, and blocking operations typically are not scalable. However, you might need to use blocking actions for some processes. The following two sections describe ways to minimize performance issues when you must use one of these action types.

For more information about these actions, see:

• Push Fields action
• Set Fields action
• Using Run Process and $PROCESS$ commands

Consider using filters instead of active links to perform Set Fields and Push Fields actions, especially if the active link Execute On condition is Submit or Modify. The advantage is that the server (filter) should perform the Set Fields action faster than the client (active link). For example, an active link that performs a Set Fields action on submit pulls information from the server, only to push that information back. Your system performance will improve if you use a filter to perform the Set Fields action at the server.

Use only efficient searches in these actions, especially if workflow executes the search frequently. Efficient searches define where the system looks for the data (usually using an index). You can also improve performance by designing your actions to retrieve only the columns needed. This is especially true when the excluded columns are diary fields or attachment fields. The biggest performance improvement, however, will still depend on how well the search is defined.

Set Fields and Push Fields actions that include database searches or external processes are considered blocking actions, so limit their use for best performance. To improve $PROCESS$ action performance, have one $PROCESS$ action execute one resource-demanding command and return the results to a temporary field. The remaining actions can retrieve and parse data from the temporary field. For example, if you are setting five fields, write this data to a temporary field with the first $PROCESS$ operation, and have the remaining actions retrieve the data from the local field.

An even better solution is to redesign the process to take advantage of the Filter API, as described in Developing an API program. This technique uses one long-running process, making it more efficient and significantly faster.

Take note of the following issues when you create join forms:

• If you create multiple layers of join forms, you might see a decline in the speed of database and system performance.
• Make sure that you only join fields that have been indexed. Joins on non-indexed fields will slow system performance.

Performance decreases when character field size exceeds 255 bytes (4000 bytes for the Oracle database). Maintain a minimum number of diary fields, because the greater the number of diary fields in a form, the greater the impact on performance for that form. Most BMC Remedy AR System applications can be designed effectively with one or two diary fields. If you are maintaining multiple form views with trim or control fields, do not duplicate screen objects unnecessarily. Whenever possible, share screen objects between views. The more screen objects you create (data fields, control fields, and trim), the larger you make your forms and the longer it takes to load, display, or switch to another view. Avoid using many toolbar buttons with different bitmaps in multiple views; this also increases the form size.

If you need to include an image, try using a JPEG instead of a bitmap. The file size is generally smaller for JPEG files, and the form will take less time to load.