There have been a series of performance related items for asset, location, and work order queries so I don't want to say there's not a product related issue in that space negatively impacting your experience. But when you see variability in performance (IE an API request to MXAPILABORCRAFTRATE takes 5 seconds one time and 1 second a second time to make the same request), you're often looking at something more fundamental. I would review the IBM performance best practices (Best Practice - Maximo Application Suite (MAS) Performance Wiki), particularly around the database.
Oracle for example the CURSOR_SHARING=FORCE is a significant one for API requests because there's a lot of similar but different queries that get executed as part of your request.
SQL Server removing the selectMethod=cursor from the mxe.db.url can similarly have a decent impact in these bulk query scenarios.
General database maintenance activities (updating statistics, rebuilding fragmented indexes, etc.) is another good area to focus on.
Performance related settings like mxe.db.UseSiteListInQuery for when users do not have access to all sites should be reviewed as well. This one in particular adjusts how the data restriction is built for site level objects and can drastically improve performance of the data restriction Maximo generates.
Triaging Maximo performance is a complicated skillset because there are so many different areas between Maximo settings, configurations the customer has made (conditions, automation scripts, etc.), ability to analyze Java code for logic flaws, and then a fundamental understanding of database performance. Even the performance best practices are guidelines rather than answers you should follow directly. The number of Oracle cursors, whether to enable the SQL Server prefetch rows setting, etc. are decisions that require thoughtful analysis before implementing.
------------------------------
Steven Shull
Principal Maximo Solutions Engineer
Naviam
Cincinnati OH
------------------------------
Original Message:
Sent: Fri December 05, 2025 11:43 AM
From: Prathamesh Kulkarni
Subject: MAS Role based application is slow. APIs are giving slow response
Thanks, Steve, for your response.
Typically seeing slowness is observed in Technician application, and for API calls for object structures MXAPIOPERLOC, MXAPIASSET, MXAPIWODETAIL..sometime observed slowness on MXAPILABORCRAFTRATE too.
Other suggestions your provided mxe.db.logSQLTimeLimit, /maximo/oslc/graphite/mobile/requests are being looked at.
------------------------------
Prathamesh Kulkarni
Original Message:
Sent: Fri December 05, 2025 08:26 AM
From: Steven Shull
Subject: MAS Role based application is slow. APIs are giving slow response
Do you have Health installed? Or Spatial/map data configured including service addresses?
Health extends the outbound definition class on the mxapioperloc object structure to retrieve some health data even when not needed. I have seen significant performance hits here (as well as asset) when you start having scores calculated. You can easily test this by duplicating the object structure and changing the outbound definition class from psdi.iface.app.location.MoutHealthOperLocProcess (the Health version of the class) to psdi.iface.app.location.MoutOperLocProcess (the base Maximo version of the class).
Spatial/maps are the geometry data is attempted to be built from the map and will have a performance impact. The best way to test this is to remove the autolocate & geometry attributes from the API request and see if the performance changes.
Beyond that, I like to set the mxe.db.logSQLTimeLimit to a lower value (like 100 ms instead of the default 1000 ms) and then make the API request and see if I see any entries in the logs of long running queries with my correlation ID. Often with these API requests it's not one extremely poor performing query, it's many individual queries that collectively add up. This can help you pinpoint what the issue might be.
If that doesn't lead to you where you need to go and you don't have something like DataDog, Instana, etc. to review performance, then I would slowly remove attributes from the request to try and identify the bottleneck.
Since you're completing about the RBA app, you should be able to grab the exact network request from developer tools. If you are trying to troubleshoot Maximo Mobile and are on 9.0+, then you should hit the /maximo/oslc/graphite/mobile/requests endpoint to get the exact request Maximo Mobile will make (it's more complicated since multiple datasources across applications are combined into a single request).
Also, don't forget about automation scripts, data restrictions, etc. I have seen a lot of customers with object or attribute initialize automation scripts that don't realize the performance impact these have because it's normally firing on 1 or 20 records instead of thousands. If you're in MAS, there is a system property (mxe.script.deactivateall) that can allow you to disable your automation scripts without needing to manually go into each one. On 7.6 you can put the instance into admin mode which would disable most automation scripts.
------------------------------
Steven Shull
Principal Maximo Solutions Engineer
Naviam
Cincinnati OH
Original Message:
Sent: Thu December 04, 2025 06:02 AM
From: Prathamesh Kulkarni
Subject: MAS Role based application is slow. APIs are giving slow response
Hi,
We are seeing slowness in Maximo RBA applications. Slowness is observed when creating new work order, updating existing work order, editing work log. Observed that, MXAPIOPERLOC API call is taking more time than expected. Analysis saved query, it is fine-tuned, returning 45k locations.
Any other area, configuration to look for to improve performance?
------------------------------
Prathamesh Kulkarni
------------------------------