Design

In addition to the configuration issues described elsewhere, there are design choices that you can make that will lower performance. The Service Desk designers provide a wide range of design choices, some of which have little or no effect on the performance of the final system, and some that can have a significant effect on performance. In some situations, it can be appropriate to make design decisions that lower the performance of the system – however, these design choices must be limited in their use and, wherever possible, not used for commonly used areas of the system.

General observation

At every stage of your design consider what you are asking the system to do, and ask yourself if it is likely to reduce the system’s performance. If it is likely to affect performance, ask if it is really necessary.

You could create a complicated query that automatically refreshes every five minutes - and this could be a perfectly reasonable design requirement for a particular analyst at a particular time. However, making that query available to all analysts all of the time will impact performance. It is better to design the system so that the query is made available only when it is needed, and only to the analysts who actually need it.

Similarly, if analysts using Web Desk need only a subset of the available fields most of the time, then design the system so that the window displays only the fields they need.

You can improve the performance of a system considerably by considering the performance effects of design decisions at every step.

Query design

Related attributes (for example, User.Title from Incident) added to a query increase the number of database joins that are needed. Adding a large number of these to a query can therefore make the query run slower. Where possible, add related attributes of this type to the query’s Preview panel - these are then displayed only when the record is selected in the query results.

Similarly, where possible, add large text fields to the Preview panel where they can be more easily read, rather than to the results list.

Query configuration

When designing queries, set them to launch within their own window, and do not set the query refresh rate too high. If you have a query that is constantly accessing the database because it has been set to refresh frequently (particularly if a lot of analysts are going to be running the query at any one time), this will reduce performance.

Dashboard design

You can add a large number of queries of any type onto the dashboards: however, we recommend that you do not add more than 2 or 3 queries on a screen. Also note that the more complex a query is, the more resource is required to display the query results. Slow login times can often be attributed to the queries added to a dashboard. Also consider whether the Home page has to be set to the dashboard, or whether it is better to add the dashboard as a component on the shortcut bar, so that it can be accessed whenever required - but not automatically at login.

Only add queries that are actually needed all of the time to a dashboard. Add shortcuts to queries that are needed on a more occasional basis – then they are run only when they are needed. Also, do not set the queries to refresh automatically more often than is necessary.

The dashboard has to run all of its queries each time it is displayed, so include on your dashboard design only queries that are set to launch results in a new window when an entry is double-clicked. In this way the user can return to their dashboard without re-running all of the queries.

Process collections on Group

Collections (one-to-many relationships within the database) can cause performance issues. In particular, there have been instances of systems having Incident, Problem or Change collections on the System\Group object. These collections can have a very bad effect on performance, and we strongly recommend that you remove these collections.

To remove process collections from the System\Group object:

1. Within the Object Designer, open the System branch and display the Group object.
2. If there are any collections present for Incident, Problem, or Change delete them.

Avoiding large collections (unbound collections)

The best way to avoid large collections is to make sure that your class model does not include any 'unbounded' collections. An unbounded collection is any collection that is likely to grow as the size of the database grows.

For example, Incident-Notes is a bounded collection because one would normally expect an Incident to be open for a finite period of time and for the number of Notes to be limited by the amount of information attached to that one Collection. On the other hand, a Category-Incidents collection would be unbounded because you would expect the number of objects in the collections to increase as the size of the database, ie the number of Incidents logged for each category grows.

Whenever you create a relationship in Object Designer ask whether it is likely to lead to an unbounded Collection attribute. If so, then make the relationship one-way.

A script is available from Ivanti support that checks for unbounded collections.

See The effect of unbounded collections on system performance on the Ivanti Community for more information.

Configuring queries or filters below the window (tabbed queries)

You can add and modify queries or filters in a tab below a window in Window Manager. This can provide your analysts with useful information such as what other incidents have been logged by a particular user, or what CIs are associated with the user. However, it is important not to overload the system with too many resource-hungry queries. Every time an analyst updates an incident they will be running the tabbed query or queries associated with the incident window. If the query is complex it may take some time to return data on the window.

If you want to have these queries or filters on tabs below a window, DO NOT add them to the first tab - as this tab is always displayed. The data for subsequent tabs is not retrieved until the tab is clicked (unless the queries are set to auto-refresh).

The data for queries that are set to auto-refresh is also ALWAYS retrieved when the window initially displays, and then is retrieved again after the refresh interval - even if the tab is not clicked. As a result of this, DO NOT add queries or filters that have auto-refresh settings to windows.

Also, limit the number of records that are displayed per page for these queries, as this will improve performance, and as these queries are being displayed below a window there will be less space for them to display a large number of rows anyway.

After Read Calculations

Avoid running large queries that contain After-read calculations, because a calculation is performed on each row that is returned by the query. If there are a lot of calculations to perform this can add an overhead on to the query.