Reserve performance

Apply best practices to increase the performance of reserve queries within your Reserve application. The query response time can vary greatly depending on the data composition and setup of the application.

Filtering

When running a reserve query, apply filters to ensure the query searches against the smallest result set possible. Fewer records in the result set mean the reserve query needs to check the availability of fewer records.

For example, floor pagination and floor filtering might be added to a building to increase performance. If a reserve query is changed to search a floor instead of the entire building, it improves performance if those spaces are spread out across many floors. Changing the application design to require a user to pick a floor before performing a search and providing a next floor option reduces the reserve query time. Apply filtering of all kinds at every possible instance to ensure that the reserve query checks the smallest result set for availability.

For more information, see Managing reservations and reservable resources .

Empty filter

In many applications, a reserve query is run when the form initially loads, and immediate results are returned. This behavior impacts the form load time. Eliminate this behavior by setting up the application to filter against a building that has zero spaces. This placeholder building can be named <Select a building>, and this building can be added to the form and set as the default building when the form loads. This filter results in faster form loading times. When the user changes the building selection, the query then searches for available spaces, which removes the execution of the query when the form loads.

Enable directed search

By setting the quantity in the triAvailabilityResultsLimitNU numeric field, the direct search feature enables a reserve query to stop processing and return results when a set number of records are found. Enable direct search by adding the triAvailabilityResultsLimitNU field to any object and form where the reserve query is being run. The platform looks for this field and uses the value to limit the results.

For example, if a site that is being searched has 1000 available spaces, then set the triAvailabilityResultsLimitNU field to 25. The search stops processing when the first 25 results are found. This feature allows users to search a large results set and maintain performance. If the field is 0, then the query returns all results. This field can also be incorporated into the application design to enable a user to specify the number of records they want to be returned. For consistent searches, the field can also be hidden with a default value. From a usability perspective, the user sees immediate results and the reserve query does not process any longer than necessary.

Enable multi-threading

Multi-threading enables a system administrator to specify the total number of threads that are available to the reserve query and how many threads each reserve query can consume. Tune the following properties based on how many concurrent reservations you expect to run at one time.

Add the following properties to the TRIRIGAWEB.properties file:
ENABLE_CONCURRENT_AVAILABILITY
If set to true, multi-threading is enabled.
CONCURRENT_AVAILABILITY_POOL_SIZE
Specifies the total number of threads that are available to the reserve query.
CONCURRENT_AVAILABILITY_REQUEST_BATCH_SIZE
Specifies how many threads each reserve query can consume.

The following are example values from the TRIRIGAWEB.properties file:

# Determines whether process Reserve Queries concurrently.
#
ENABLE_CONCURRENT_AVAILABILITY=true

# If ENABLE_CONCURRENT_AVAILABILITY is true, this is the maximum number of system wide
# threads that will be used in processing availability.
#
CONCURRENT_AVAILABILITY_POOL_SIZE=200

# If ENABLE_CONCURRENT_AVAILABILITY is true, this is the maximum number of threads each
# availability request can use to process availability.
#
CONCURRENT_AVAILABILITY_REQUEST_BATCH_SIZE=10

Debugging reserve

To debug the performance of directed search and multi-threading, add the following categories as manual categories, to the Platform Logging Manager in the Administrator Console.

  • com.tririga.platform.concurrent
  • com.tririga.platform.query.reserve

Performance indexes

The following indexes improve Reserve performance in IBM test environments:

Avoid all-day meetings

When you use the Reserve application, do not use all-day meetings, especially when integrating Reserve with Microsoft Exchange. Microsoft Exchange treats all-day meetings as floating meetings with variable start and end times that are based on the viewer's time zone. This treatment is problematic when you are coordinating the usage of shared resources across multiple time zones. Maximo Real Estate and Facilities treats all-day meetings as 24 hour meetings that are based on the organizer's time zone. However, it is not a best practice to reserve shared resources for 24-hour increments. So, if possible, train your users to avoid all-day reservations.

Room search page size

By default, the Maximo Real Estate and Facilities Room Search add-in for Microsoft Outlook displays 10 available meeting rooms per page. To change this default value, you can select Tools > System Setup > General > Application Settings. Open the Reservation Settings tab, scroll down to the Perceptive Reserve App Settings section, and specify a new value for the Search Rooms Page Size field.

For more information, see Installing the Room Search add-in in Microsoft Outlook.

Availability section maximum settings

When the Availability section is rendered, the AVAILABILITY_SECTION_ROW_LIMIT property in the TRIRIGAWEB.properties file limits the maximum number of results to the specified value. If there are too many results, then a warning about exceeding the row size is displayed. The default value is 50 rows. If the value is set to 0, -1, or another invalid value, then the default value is used.

Important: If the property value is too high, performance issues might occur when the Availability section is rendered. Large values might cause memory issues. It is recommended that you update the underlying reserve queries to reduce the number of results or design the filters to limit the number of results under this value. Any specified value greater than the maximum value of 500 is set to 500.

In the Availability section, the CALENDAR_EVENT_MAX_OCCURRENCES property in the TRIRIGAWEB.properties file limits the maximum number of occurrences that are displayed and created for recurring meetings to the specified value. The default value is 20 occurrences. For example, if you create a recurring event that occurs every week for a year, which is 52 occurrences, then only 20 occurrences are displayed and created in the Availability section. To change this limitation, you can change the default value to another value.

Important: If the number that you specify for the property value increases, then the probability that performance degrades also increases.

For more information, see Setting up reservation results in the Availability section.