Server and client performance
The server performance information is this topic focuses on Indexes, Queries, and Data storage. See also Best practices for client performance below. This topic also includes General performance tips.
Forms in the applications should be properly indexed. The fields that are queried the most should be indexed. The number of indexes on a form, however, should be limited. For example, indexing five or fewer fields is usually best, but indexing seven is acceptable. Also, fields that have many modifications should not necessarily be indexed.
When you are assessing your indexes, BMC suggests that you ask 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?
In a query, indexed fields should always be evaluated first evaluated, followed by any nonindexed fields. Also, avoid LIKE qualifications that are formatted as %Field% because this forces 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 multiples when 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.
Avoid setting the Query-by-Example (QBE) options on fields to Anywhere, which results in a full table scan if those fields are the only ones being queried. The preferred QBE option on fields is either Equal or Leading. Anywhere is used only for selective fields; for example, the Approvers field (Field 13207) from BMC Remedy Approval Server. For more information, see the QBE Match field property description in
As part of the development process, you run the BMC Remedy Developer Studio Analyzer to find any obvious issues that need to be fixed. Run Analyzer during the entire development phase of the project to ensure that issues are being resolved. Do not leave this task to the end of the development phase. For more information, see
When you are assessing your queries, BMC suggests that you ask the following questions:
- Can the query be done in a filter (which executes on the BMC Remedy 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 BMC Remedy Developer Studio Analyzer been run and the flagged objects reviewed?
- Has the QBE option for character field been set to Equal or Leading?
Consider whether data should be stored in a single form and or in separate forms. Data that is clearly not part of a component should have its details stored in a separate form. For example, the detailed information about a person should be stored in a separate person form. You can, however, store specific data about that person in an application form. For example, to make queries and permissions work, you should store the logon name of the person in a help desk ticket rather than querying for it each time the ticket is displayed.
If the data is stored in separate forms, consider how the data should be referenced. If there is a many-many type relationship between data, use an association type table. However if there is a 1-1, 1-many, or many-1 relationship, store the link as a foreign key. There are exceptions to this rule depending on the needs of the application.
To avoid an performance impact, keep character fields under 255 characters in length.
Data storage assessment
When you are assessing data storage, BMC suggests that you ask the following questions:
- Where should data be stored and which component does it belong to?
- How is the data referenced and should an association table or foreign key be used?
- How many fields are over 255 characters and do they need to be?
Best practices for client performance
This section provides our recommendations to assist you in designing for 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 if 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 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. Try to reduce the number of window open and load operations because they appear to make the application slow. Changing the characteristics of a field (for example, visible, hidden, enabled, disabled) is an expensive operation in browsers. 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 allows the window to load quicker. If workflow then makes the field visible, the visual affect to the end user is more seamless.
Reduced the number of fields on forms
Large numbers of fields, and especially table fields, reduce the client's load time, especially on the web.
Limit the number of table fields and manage new additional fields with careful consideration for 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. Table fields should be refreshed only if the page holder they are on is set in focus.
Remove fields from the views wherever possible to reduce the web footprint. BMC Remedy 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
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
- Do not let the same workflow start on window open, window loaded, and set default events. To avoid this, create a guide and check for the initialized values of some fields. For example, suppose you have designed some workflow which starts on window open and loaded, and performs a lookup in multiple back-end forms. If this workflow starts on both events, the workflow does multiple lookups and half of the queries are repetitive and useless.
- Do not let several workflows that check the same qualification start on the same event. For example, suppose 15 active links start on the Save button and check some common condition to perform some validations. All 15 links have the same qualification on Run If, so the server validates the qualification for all 15 links when the save event occurs. Checking the same condition is redundant. To avoid this, create a guide and include all the related workflow in that guide so that if the condition fails it does not check the other workflow.
- Do not use change field actions on window open events to hide the fields in all the form modes (new, search, and modify). This creates a performance problem on the web. For example, suppose that a form has 100 fields and at least 50 fields are hidden when the form is opened in new and search modes. If workflow exists to hide the fields in both new and search modes, at least 50 change fields are needed. Instead of hiding through workflow, you can initially hide the fields on the form and make them visible when necessary. The best practice is to initially hide the fields on the form and make them visible when the context changes.
- Do not let change field actions start to show or hide the fields on the pages that are not visible for window open events. For example, suppose that a form has multiple pages. On window open events, only one page is displayed to the user. In this case, do not start the workflow, which makes the fields show or hide on a non-displayed page. Move all the related change fields so that these fields gain focus in that particular page. By doing this, you take the workflow load off of window open event. For more information about the Gain Focus workflow execution option, see .
- As part of 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 should now be 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.