Performance tips

Duplicate calls

Use the browser’s Network tab to analyze the requests made by your application. You might notice duplicate requests, which could be the result of incorrect JavaScript logic or event handling issues.

Look for pageSize

For example - do not give a big pagesize when you are going to show only a few. General rule of thumb - make it 1:2 - so if you are planning to show only 10 - give a pageSize of 20.

Look out for attributes in oslc.select clause

Dot notation attributes

Using relationship-based selects in OSLC queries can significantly impact performance.

For example, consider the following query:

    oslc.select=assetnum,description,location.description,location.location,site.description,siteid
  

This query performs worse than a simpler version:

    oslc.select=assetnum,description,siteid,location
  

With a pageSize of N, the first query triggers 2N + 1 SQL statements—one for the asset table, and one each for the location and site tables per asset. For 100 assets, this results in 201 SQL calls.

Additionally, location is a native attribute of the ASSET table. Using location.location unnecessarily forces a lookup via relationship, resulting in redundant SQL calls. In this case, the performance impact is already incurred due to location.description, but avoiding unnecessary relationship-based selects remains a best practice.

oslc.select=*

A common mistake is selecting all attributes from an object structure or MBO, even when only a subset is needed.

Domain description

It’s common to require domain descriptions for attributes such as status and other domain-bound fields. To support this, the REST API framework maintains a multilingual (ML) cache that stores descriptions for various domains. When domain-bound attributes are detected, the framework automatically adds the corresponding description from the cache to the response JSON. However, many REST API calls include a select clause that retrieves domain descriptions via relationships, bypassing the cache and resulting in additional SQL queries.

Fetching count

There is a simple API call to fetch count <rest collection url to the resource>?count=1. When fetching only a count, avoid using oslc.select or collectioncount=1, as these options trigger MBO initialization and result in unnecessary SQL queries. For optimal performance, use a minimal query that retrieves only the count.

To retrieve the count of child objects alongside parent data in a REST API call, use the _dbcount suffix in the oslc.select clause.

The following syntax can be used:

        oslc.select=assetnum,description,location._dbcount
      

In this example, location is the Maximo relationship name linking the parent object (asset) to the child object ( location records). The _dbcount suffix instructs the framework to return only the count of related records, avoiding full MBO initialization and improving performance.

To fetch count of a child object with no data from parent, use the GET call /os/<os name>/{id}/<relation to child object>?count=1

Fetching data for other tabs while in one tab

In an multi-tabbed application, there is no need to fetch data for tabs that are not visible yet. Just-in-time fetching helps improve the app loading performance.

Lookout for properties header for POST requests

This is similar to oslc.select in GET cases. We should look out for things that we do not need - for example domain descriptions, imagelib references etc which are automatically populated. We don't need to explicitly specify them. Specifying them are costlier. Also avoid doing properties=*.

Sorting on non-indexed attribute

One of the common mistakes we see is rest queries use of oslc.orderBy clause sorting on non-indexed attributes like say description.Sorting on attributes that is not indexed will have a performance cost on the query. While developing the apps, consider not sorting by default and just use the order that the database provides. Let the end user drive the sorting.

ignorecollectionref=1 query parameter

This is another area for optimization. We can set this query parameter to 1 and reduce the size of the JSON payload response in cases when we are requesting data from a big OS like MXAPIWODETAIL. This will remove the collection ref to child collections from the response JSON. We should leverage it in our list page collections.

Evaluating/filtering data at the server side

Look for evaluating/filtering data at the server side as opposed to client side and only transfer required data to the client, effectively filter at the server as opposed to getting all data and then filtering on the client side.

Optimize selecting related MBOs

This use case deals with situations where we are getting information from a related MBO on a collection of selected MBOs. For example we try to get information on locations and sites for a given set of Assets. Now if from a collection of 100 Assets, we have 20 distinct Locations and 5 distinct sites – we will still end up firing 100 + 100 = 200 SQL queries for each asset loading the site and location individually. To optimize that we need to make sure we have entries in the APILINKEDOBJECT table for the relations in use from Asset->Location and Asset->Site. A sample Asset->Location is shown in the following example. This tells the system that Asset is related to location using the matchexpr which helps the system to maintain a transient cache (of locations) while creating the JSON from the collection of Assets.

This will help reduce the number of queries to just the needed 20+5 based on unique locations and sites.

Aggressive fetching of data vs fetching data as needed

Avoid fetching all children objects in an object structure at once. Consider fetching those as needed basis for example if the requested by the end user. For example to fetch PO such that we can show it in a UI table/List, the POLINES and Terms might not need to be fetched. They can be fetched after the POs are populated and as the user wants to drill down into the individual POs. This REST API provides various ways to enumerate a child relationship and those can be leveraged for this.

Troubleshooting Performance

This section discusses how to debug and generate the SQL for your rest calls.

One of the ways we can troubleshoot performance of an API call is by checking the amount of SQL it's generating. The simplest way to do that would be to enable thread logging for the context oslc and for the user you intend to use for testing. This can be done using the “Custom Logging” action from the logging app -> Thread Logging. Note you need to enable the logger type – in this case SQL. Note if you want to track other loggers feel free to set them up as well here for the “oslc” context. Once you start making the rest API calls – you should see a file getting generated under your application server working directory that will have a naming convention like OSLC_XXXXX.log and that will contain all the SQLs and other logs that this API call generated