Server and client performance

To achieve a better server and client performance, follow the tips and best practices that focus on Indexes, Queries, and Data storage.

Indexes

Properly index forms in the applications; especially the fields that are queried the most. Limit the number of fields to be indexed to no more than seven. Also, avoid indexing the fields that have had many modifications.

Index assessment

When you are assessing your indexes, we recommend that you consider the following questions:

Are the fields that are queried against most often indexed?
Are there too many indexes on a form?
Are the fields that are being indexed modified often?
How many API calls are generated when the function is used or called?

Queries

In a query, indexed fields are always evaluated first, followed by any non-indexed fields. Also, avoid LIKE qualifications that are formatted as %Field% because they force a full table scan. An exception is including such a qualification after an indexed search to reduce the result set.

Know how many queries are being performed during any operation. The number of queries performed during an operation is multiplies when a load is put on the system, resulting in degraded performance.

Client-side queries add a load to the application because they are performed over the network. If you can consolidate these queries, or perform them on the server, you reduce the number of queries and server calls.

Use the Query-by-Example (QBE) options on the character fields that have the QBE Match property set to either Equal or Leading. Anywhere is used only for selective fields; for example, the Approvers field (Field 13207) from Approval Server. If you set the QBE option to the fields with QBE Match property set to Anywhere, this setting will result in a full table scan; even if those fields are the only ones being queried. For more information, see the QBE Match field property description in Field Properties Open link .

Query assessment

When you are assessing your queries, BMC suggests that you consider the following questions:

Can the query be done in a filter (which executes on the AR System server) rather than the client?
Can multiple queries be consolidated into a single query?
Can the data be stored rather than queried for?
Has the Developer Studio Analyzer been run and the flagged objects reviewed?
Has the QBE option for the character field been set to Equal or Leading?

Data storage

Consider whether data is to be stored in a single form and or in separate forms. Data that is clearly not part of a component must have its details stored in a separate form; for example, if the detailed information about a person is stored in a separate person form, you can store specific data about that person in an application form, and to make queries and permissions work, you must store the login name of the person in a help desk ticket rather than querying for the name each time the ticket is displayed.

If the data is stored in separate forms, consider how the data is referenced. If there is a many-many type relationship between data, use an association type table. If there is a 1-1 (one-to-one), 1-many (one-to-many), or many-1 (many-to-one) relationship, store the link as a foreign key. There are exceptions to this rule depending on the needs of the application.

To avoid impact on the performance, keep the character field length to less than 255 characters.

Data storage assessment

When you are assessing data storage, we recommend that you consider the following questions:

Where does the data need to be stored and which component does it belong to?
How is the data referenced and do you need to use an association table or a foreign key?
How many fields exceed the limit of 255 characters and does the length need to be more than 255 characters?

Best practices for client performance

This section provides our recommendations to assist you in designing for better client performance.

Efficient server access

Monitor the number of API calls made to perform the most common operations. If excessive calls are made, performance for a single user might be fine, but multiple concurrent users could overwhelm the server. Enable client-side API and active link logging, specifying both to the same log file, capture the operation, and see how many API calls are being made. Verify whether they are all required or if some could be consolidated, thus reducing the API calls from the client to the server.

Optimized window open actions

Ensure that the actions are performed only in the appropriate place when a new window is opened. Look for actions that execute on both window open and load operations. Reduce the number of window open and load operations because multiple load operations make the application slow. Changing the characteristics of a field (for example, visible, hidden, enabled, disabled) is an expensive operation in browsers that impact performance. Design the application so that the initial state of the fields is the state that is most common for the initial opening of the window, and use change field actions in active links only when it is necessary. The preferred initial state of such fields is hidden, which enables the window to load faster. When a workflow makes the field visible, the visual affect to the end user is more seamless.

Reduce the number of fields on forms

Large numbers of fields, especially table fields, reduces the client loading time, especially on the web.

Limit the number of table fields and manage new additional fields with careful consideration of performance. Refresh table fields only when necessary. Refreshing a table field if a user is not viewing it affects performance because it requires a query to the database and information flowing back. Refresh the table fields only if the page holder they are on is set in focus.

Wherever possible, remove fields from the views to reduce the web footprint. Mid Tier takes an optimum path for hidden fields that are not made visible; however, such fields are kept to a minimum (for example, selection fields whose values must be extracted by arlabel).

Optimize temporary field usage

Reuse temporary fields. A large number of fields makes the view and JavaScript files larger, and requires more time to open the form.

Global field ID usage

Be selective about global field ID usage and avoid global fields unless necessary. Data storage by many global fields results in additional memory being used and results in slower workflow processing.

General performance tips

Create a guide and check for the initialized values of some fields to avoid the same workflow to start on window open, window loaded, and set default events; for example, if you have designed a workflow which starts on window open and loaded, and performs a lookup in multiple back-end forms. If this workflow starts on both the events, the workflow does multiple lookups and half of the queries are repetitive.
Create a guide and include all the related workflow in that guide so that if the condition fails it doesn't check the other workflow. Avoid starting several workflows to check the same qualification on the same event; for example, if 15 active links start on the Save button and check a common condition to perform some validations, all the 15 links have the same qualification on Run If, so the server validates the qualification for all the 15 links when the save event occurs. Checking the same condition is redundant.
Initially hide the fields on the form and make them visible when the context changes. Do not use change field actions on window open events to hide the fields in all the form modes (new, search, and modify); for example, if a form has 100 fields and at least the 50 fields are hidden when the form is opened in new and search modes. If a workflow exists to hide the fields in both the new and search modes, at least 50 change fields are needed. Instead of hiding the fields by using the workflow, you can initially hide the fields on the form and make them visible when necessary.
Avoid starting the workflow, which makes the fields show or hide on a non-displayed page. This approach takes the workflow load off of window open event; for example, if a form has multiple pages, on window open events, only one page is displayed to the user. For more information about the Gain Focus workflow execution option, see Workflow actions and execution options .
For a periodic application cleanup, delete the unnecessary hidden optional fields on the form. If you do not delete these fields, the table becomes very large. These fields might be the result of legacy workflow and are replaced by display-only fields.
Do not create debug fields directly on the form. Display-only fields no longer need to be in any view. If debug fields are placed directly on the form, there is not a simple mechanism to hide or show them as necessary. Many applications have added a Debug Page Holder field with the same field ID of 300037600 to all forms and placed fields on it that do not need to be visible when interacting with the application but might be needed for debugging. If you use the Debug Page Holder field, do not place it on any view that will be opened by a user role; the extra fields on the view will reduce performance especially for those connecting over a WAN. Some applications have a view called Default Administrator View (or Administrator) where all fields including the Debug Page Holder field are placed. There is a development maintenance cost associated with such a view, however, and this extra view adds extra load to the client so you should eliminate it from the final version of the application. You may choose to keep this view during the development process. Fields that do not need to be visible but yet are required on views (for example, some table and selection fields) should be placed below the visible fields in a position less than the visible field width. Such hidden fields require field help text and a grouping mechanism may be put in place.
To initialize fields, use minimum active links with minimum actions to set the default values instead of using different active links to set the default values for each field. If the number of active links increases on the form, the performance on the web decreases.
Ensure that all GUID fields have the QBE option set to Equal. Use the Equal QBE option instead of Anywhere. Anywhere causes a full table scan to search for the content in the database table.
Do not keep menus attached to hidden fields. The opening of forms is impacted if these menus are on the On Connect event. When you copy fields from another form and keep those fields in other forms as hidden debug fields, remove attached menus that are not needed.
In a push fields action, do not put the false condition to create entries. This leads the database table through a full table scan. Instead of providing a false condition like 1=2, leave the qualification blank, and for the If Any Requests Match option, select Take No Action.