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.
- 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:
- Reserve indexes in Tuning the IBM DB2® indexes
- Reserve indexes in Oracle database
- Reserve indexes in Tuning the Microsoft SQL Server indexes
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 . 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.
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.
For more information, see Setting up reservation results in the Availability section.