Maximo

Maximo

Come for answers, stay for best practices. All we're missing is you.

 View Only

Inside Maximo Health 9.2.x: Internal Score Calculation Performance Improvements

By Mahima Nama posted 7 days ago

  

Introduction

As asset volumes continue to grow, enterprise asset management platforms need to do more than just calculate scores correctly — they need to calculate them efficiently, reliably, and at scale.

In Maximo Health, the internal score calculation engine plays an important role in evaluating asset health and other scores like criticality, risk etc. based on configured scoring groups, drivers, contributors, and formulas. While the existing implementation worked effectively for smaller workloads, large-scale datasets introduced significant challenges around runtime, memory usage, database round-trips, and fault tolerance.

With Maximo Health 9.2.x, the internal score calculation process has been optimized to improve performance, scalability, and reliability for large asset portfolios.

The Challenge with the Earlier Architecture

In the earlier architecture, score calculation followed a mostly sequential, row-by-row processing approach.

At a high level, the flow looked like this:
Assets under a Scoring Group
  → Single Asset MBO Processing
  → Score Calculation
  → Individual Save per Asset
  → Commit per Asset
  → Repeat for all Assets

This approach had a few major limitations when processing large datasets:

  • High number of database round-trips
  • Many individual transactions
  • Higher memory usage due to MBO object lifecycle overhead
  • Longer runtime as asset count increased
  • Risk of one problematic asset impacting the overall calculation run
For smaller datasets, this model was manageable. However, once workloads increased to hundreds of thousands of assets, the runtime became a significant bottleneck. In one such large workload scenario with 150K assets, the score calculation took approximately 37 hours making the earlier approach impractical for larger deployments.

Optimized Architecture in Maximo Health 9.2.x

The optimized architecture introduces a batch-driven and parallel processing model. Instead of processing each asset independently from end to end, assets are grouped into configurable batches and submitted to a thread pool for controlled parallel execution.
Note that the calculation using the formula and contributors remain same.

The optimized flow can be summarised as:

Asset under a Scoring Group
  → Batch Creation
  → Thread Pool Executor
  → Parallel Batch Processing
  → Score Calculation
  → Collect Results of All Assets in the Batch
  → Batch SQL Execution
  → Commit per Batch

The default batch size used for score calculation is 500 assets, with configurability up to 1000 assets per batch. The default thread pool configuration uses 4 core threads and 4 maximum threads, and these values are configurable based on workload and infrastructure capacity.

For the same 150K asset workload, the optimized architecture reduced score calculation time from approximately 37 hours to 4.35 hours, delivering an 88% performance gain.

image

How the New Processing Model Works

1. Batch Creation

Assets are grouped into batches before calculation begins.

For example:
Batch 1: A0001 – A0500
Batch 2: A0501 – A1000
Batch 3: A1001 – A1500
...
Batch N: ... – N
This reduces the overhead of processing and saving each asset independently and allows the system to operate on asset groups more efficiently.

2. Thread Pool-Based Execution

Batches are submitted to a thread pool executor. The thread pool is created per scoring group execution and uses configurable core and max thread settings. The core thread count specifies the minimum number of worker threads that the thread pool tries to maintain. The maximum thread count specifies the upper limit on the number of threads that the thread pool can create during periods of high load.

Default configuration:
Core threads = 4
Max threads  = 4
Batches that cannot be executed immediately are placed into a LinkedBlockingQueue. Only batches up to the configured max thread count are processed in parallel. When a thread completes one batch, the next batch is picked from the queue. This provides bounded parallelism and prevents uncontrolled resource usage.

3. Per-Batch Independent Processing

Each batch follows its own independent lifecycle:

Calculate Scores
  → Collect score results of all assets of this batch across all the tables
  → Execute Batch SQL in all tables
  → Commit per batch
The important point is that results are collected within the batch, not across all batches globally. Each batch independently executes SQL batch operations and commits independently. This avoids cross-batch aggregation and improves fault isolation. The optimization uses JDBC batch operations such as addBatch() and executeBatch() for scoring-related data persistence. 

Key Improvements Observed

1. Consistent Performance Gain in Runtime

The optimized architecture delivered an average of approximately 80% reduction in score calculation time across tested workloads. The improvement becomes more significant as dataset size increases, which indicates better scalability for large asset volumes. Refer the image below for performance gains across various workloads.

image


The detailed runtime comparison gives a more granular view of the measured improvement.

image

2. Improved Memory Efficiency

The new architecture showed an average of around 50% lower peak memory usage for large workloads. In larger datasets, memory savings are more visible because batching and improved object lifecycle management reduce the number of active MBO sets and related objects held during processing.

Performance improvement is not only about reducing runtime. Resource consumption is equally important for production workloads, especially when large score calculation jobs run inside constrained pod environments.The resource usage comparison for 150K assets shows that memory usage reduced significantly after optimization. With a batch size of 500 and max thread count of 4, peak memory usage reduced from 14 GiB to 6.65 GiB, while JVM heap usage reduced from 5.27 GiB to 1.21 GiB. This indicates better object lifecycle management and reduced MBO overhead during calculation.

image

3. Reduced Database Round-Trips

By moving from individual save operations to batch SQL execution for scoring tables, the number of database round-trips is reduced significantly.

Conceptually, the database operation pattern changes from:
N individual operations to N / batch size batch operations

This directly contributes to faster completion time and lower transactional overhead.

4. Better Fault Isolation

In the earlier model, sometimes one corrupted or problematic asset could impact the full scoring run. The optimized approach improves fault tolerance by isolating failures at the asset level. 

That means, if one asset encounters an issue, processing can continue for other valid assets, reducing the need for manual reruns.

5. Better MBO Set Efficiency

Performance analysis showed a consistent 80–90% reduction in MBO sets across different workload scales. This indicates improved object lifecycle management and reduced memory pressure during large score calculation runs.

6. Reliable Default Scores Cron Execution

The 9.2 release also includes a fix for default score calculation execution through cron processing. This improves automated score calculation reliability and reduces manual intervention for scheduled score updates.

 

Resource Trade-Offs

Parallel processing improves throughput, but it also requires careful management of system resources.

The optimized architecture introduces configurability for:

  • Batch size
  • Core thread count
  • Max thread count

This allows administrators to tune calculation behavior based on available infrastructure capacity. Read this ibmdocs article for knowing more about how to configure the above.

Higher parallelization can complete processing faster, but database connections and CPU and memory usage should be monitored to ensure the configuration is appropriate for the deployment environment.

Recommendations

1. Scalable Deployment

The optimized architecture has demonstrated strong performance improvement and better scalability across large asset datasets. The new process scales more efficiently as asset volume increases. This makes the optimized architecture better suited for large environments with 100K+ assets and future growth toward even larger workloads.

2. Cost-Benefit Impact

The reduction in runtime and peak memory usage can translate into operational benefits:

  • Faster score calculation windows
  • Lower memory overhead
  • Better infrastructure utilization
  • Reduced manual intervention
  • Improved reliability for scheduled calculations

An average runtime reduction of around 80% can significantly reduce operational wait time for large asset portfolios.

Conclusion

This optimization highlights an important engineering principle:

Performance at scale is not only about faster execution. It is about designing the system to process work efficiently, safely, and predictably.

By introducing batch processing, bounded parallelism, independent per-batch SQL execution, improved fault isolation, and configurable tuning parameters, the Maximo Health internal score calculation engine becomes more scalable and reliable for large enterprise workloads.

The optimized architecture helps Maximo Health process larger asset portfolios with improved runtime, reduced memory usage, and stronger operational resilience.

0 comments
7 views

Permalink

https://community.ibm.com/community/user/blogs/mahima-nama/2026/07/19/maximo-health-92-internal-scoring-performance