In the world of Maximo, there are often little things that you wish you wouldn’t have to encounter. Slow start centers, slow search results and that dreaded spinning wheel on the screen are just some of the Maximo buzz kills that users report. If you can rule out issues of network latency, CPU utilization and other obvious reasons, then simple tweaks like the ones mentioned below may be able to help you.
~ Maximo buzz kills can be frustrating and time consuming ~
Start Center is a pretty nifty tool. To have everything stored in one place is a major time saver. So, when a start center lags, it can be pretty frustrating. What goes on behind those lovely result sets and KPI portlets, you ask? Every portlet runs queries. This is what fetches the results from the database in each portlet. Assuming each query takes about a second to execute, 5 portlets in your start center would mean that it would take 5 seconds to load everything on the start center. To solve these Maximo buzz kills, try to make sure that too many queries are not being run simultaneously. Furthermore, the default query should be compact rather than too complicated as this will also increase lag time.
~ Time lags in Start Center ~
It is a common request from clients to make available a field in an application. A common belief might be that one or two fields on the List tab won’t significantly affect performance. Such customizations are performed using the Application Designer, or by directly modifying the XML for an application. While the original intent of the customizations is convenience and being able to easily download data using the “Download” feature, there is a downside. Such customizations can create an unnecessary drain on system performance. Every time the List tab is displayed when a user hits enter in the application; the added information also needs to be fetched from the database. There is, however, a simple solution to this – instead of customizing applications to make available additional information, using ad hoc reports can help the performance. Additionally, the information you need is not displayed every time the application is loaded, but only when it is needed.
When analysing logs, long running queries are common Maximo buzz kills that most of us have experienced. Sometimes users can run poor queries, oblivious of the impact it can have on the system. Fortunately, there are some properties available in Maximo to tackle this.
Maximo provides configurable system properties that determine how long queries can run. A control is provided in the user interface so you can cancel your own queries before a configured timeout property cancels them. These configurable attributes are set in the System Properties application.
Query timeout: mxe.db.QueryTimeout.
This property represents the amount of time in seconds before the SQL query times out and is stopped.
Identify long running queries: mxe.db.logSQLTimeLimit
This property can be used to identify long running SQL statements. By setting appropriate logging levels and monitoring logs you can identify performance problems caused by inefficient user queries or the lack of a good index for a frequently used query.
We have seen cases where a report goes rogue, running for a long time and affecting negatively on system performance. There are two ways to ensure reports don’t degrade system performance.
~ Specify record limits and send notifications to your administrator to avoid long running reports ~
If there are any other handy tips and tricks that you think we missed, contact BPD Zenith and let us know!