Query performance tests - SmartPlant Foundation - IM Update 46 - Help - Hexagon

SmartPlant Foundation Help

Language
English
Product
SmartPlant Foundation
Search by Category
Help
SmartPlant Foundation / SDx Version
10
SmartPlant Markup Plus Version
10.0 (2019)
Smart Review Version
2020 (15.0)

A query for interfaces or properties is a good test of performance, because it is a simple search in a single domain and should be fast. If this query performs well, and the query for tags or documents runs slowly, the issue might be with the configuration.

The query itself dramatically influences the time taken. Key points about quick finds and queries are listed below:

  • Users should try to avoid leading wild cards, such as *PUMP100*. The leading * means that the data base has to search the whole of every name string for the existence of the string PUMP100 anywhere in the name. This process is slow, as it does not use the indexes. Searching for ??PUMP100* is faster, because it looks for the PUMP100 string only, starting at the third character of the string. Be careful as wild card use can have a big impact on query performance.

  • Set the Warning dialog number user preference to a meaningful level. This feature warns users that they are about to search for and return a lot of data, which could be time consuming. Setting a warning limit of 1000 is not practical. A utility allows administrators to set some key user preferences globally to help projects maintain settings they consider acceptable.

  • Check if the users are browsing data in large sets searching for items. If so, configure paged queries to greatly improve the time for the initial search.

  • Check if the users are regularly returning large numbers of objects. If so, consider what the users are doing with the returned data. If they are using wide searches to find one or two objects, paged queries might be helpful. If they are getting large lists of data for analysis and comparison, it might be better to configure ad hoc reports exported to Excel, as these run faster and can be run in the background while the user continues with other work.

  • Check if a property filter is configured on the find and query methods, as this may be the cause of delays. Remove the filter and see if the performance is improved.

  • Check the interface being used. Using a more specialized interface improves performance by reducing the possible objects searched. Change the interface and see if the performance is improved.

  • Check to see if the users are selecting master revision or version properties when searching for documents. Change this interface on the find methods and the interface and forms on the query to see if performance improves.