Maximo Performance - A Best Practice Overview Webinar, August 27, 2014

Assured Application Performance www.reflective.com

Improve Maximo Performance(A CMMS Best Practice Webinar)

Graham Parsons – Product Manager, Reflective Solutions

Bill Thompson – Director APO Marketing Communications, Genesis


Agenda

• Why is Maximo (often) slow / unstable?• Best practises to avoid this• Don’t forget about production• How to ensure continued good performance• Q&As

Note: questions welcomed! Please use the chat to send them to the webinar organizer.


Introduction• Reflective Solutions – focused on application

performance

• Worldwide locations:– European sales, company management in London, UK– R&D and 2nd / 3rd line support office in Sofia, Bulgaria– Sales, consultancy office in Boston, USA

• Assuring Maximo application performance since 2002

• Partnered first with MRO, now IBM and many other Maximo implementation / support providers


Is Maximo Destined to be Slow?• Maximo performs well if it is:– Not highly configured – Not customized– Used in a typical way, with typical data sets– Deployed to industry best practice guidelines

• Not many organizations use ‘vanilla’ Maximo

• Many reports of slow Maximo systems (Google and Pulse / MUGs)


What Causes Problems?• Problems = Scalability,

Performance and Stability

• Maximo’s architecture is overly complex

• Usual suspects (from our experience):– Customizations– Mis-configuration / inefficient resources– Data sets / access– Other – security, unusual usage, 3rd party integrations


Projects MUST Consider Performance• Maximo is usually a critical systems

• Users will not accept poor response times / outages

• Slow Maximo can affect: – Business operation– Revenue– Costs


How to Avoid Performance Problems• Follow best practices– From IBM– From technology vendors

• If working with a partner, draw on their experience

• The only 100% method is to performance test– At a minimum, prior to release– Ideally, regularly through the project


When to Performance Test• Minimum is before release– Final version of Maximo– Final hardware (or as close as)– Final network (or as close as)

• Downside: problems detected are costly

• Recommend testing every man year or two of effort– Stable but non-production hardware– Find problems soon after they are introduced– Shorter timescales / lower cost to fix


Isn’t Testing Slow, Complex and Costly?• Yes (with old testing tools)

• LoadRunner® is common– 28 page ‘how to test Maximo’ paper

• How to fight the Maximo framework

– Requires expert LoadRunner® skills, expert regular expression skills, expert Maximo framework skills

– Tests take man months!

• New tools significantly reduce timescales and cost

• If you can, use one of these!


StressTester™ for Maximo

• Specialized version

• ‘Understands’ Maximo framework

• Load from any location

• Zero scripting= ease of use (for all team members)

• ‘Understands’ Maximo technology stack

• Automatically identifies cause of detected problems


Timescales / Skills for Performance Testing• Experience:– Someone has to state the requirements

• Skills depend on tool:– Scripting or not?– Having to understand the Maximo framework?

• Timescales depend on tool, experience, complexity of requirements

With StressTester™ for Maximo:– First test in two weeks– Repeat tests (later in project) a couple of days


Best Practises• Test as often as you can

• Simulate the full transactions– Include all that are common plus key– Every step including common alternative routes– Vary data in the same way users will

• Simulate load from the relevant locations

• Scale beyond your Maximo license limit


Our Experience – Maximo Performance Testing• 73% of tests have failed!– Based on 257 tests (5.2, 6.x, 7.x)– 7.x tests fail more than 6.x

• Typically requires three weeks to fix– Fix cause– Retest– Confirm all OK (often further problems detected)

• Projects that test throughout the project– Under 10% fail– Usually simple configuration problems


Sample Results

Maximo Performance Testing using StressTester™ for Maximo


Military Client• High (>1000) concurrent users

• Multiple worldwide locations

• Goal to simulate full 24 hour day– Different # users in different locations at different times

• Maximo 7.1, WebSphere, Linux, Oracle

• Pre-production test


Performance Degrades as Load Increases


Root Cause: Security Customization


Utilities Client• Major energy supplier

• 7-month upgrade to 7.5– Well that was the plan!

• Tested monthly throughout project


Iteration 4 (4 months)


Iteration 5 (6 months)


Maximo is released …

No problems are reported …

Time to relax?


Maximo is released …

No problems are reported …

Time to relax?

Sadly Not!


Production Problems Still Occur• Maximo is a ‘living’ system

• Data sets can vary hugely over time

• Users discover different methods to achieve a task

• User community changes

• Ad-hoc and custom reports


Why do Organizations Live with Problems?• Often, cannot state problem

• Is it Maximo or something else?– Maybe the network?

• Maximo is a ‘black box’– Doesn’t use technologies in normal manner– Non-specialized diagnostic tools struggle

• ‘Point tools’ show all is OK

“Maximo is known to be slow … nothing that can be done”


System Monitoring Tools are Available• Monitoring tools exist– Some monitor user response times– Some determine network effects– Some can monitor one or all of:

• Operating system, JVM, WebSphere/WebLogic, DBMS

• Most only make sense to an expert

• Technology vendor ‘point tools’ are little use with Maximo


Requirements of a Monitoring Tool• Monitor response times– All steps in all key transactions– From all locations

• Deep-drill monitoring of all Maximo technologies

• Automatic correlation of above in real-time

• Alert relevant people when problems occur

• Provide SLA and trend analysis info

• ‘Old’ monitoring tools tend to do some of the above and are not Maximo specific


Sentinel for Maximo• Does all the above

• Specialized for Maximo– Simple to configure– Quick ROI– Identifies problems as / before they occur– Immediate pinpoints the root cause

• Full SLA and trend analysis

• Technology experts not required


Goal: Proactive Support• At the latest, know about a

problem at the same time as the user

• Immediately understand the root cause

• Be fixing (or have fixed!) the problem before the phones ring

• React to trends before they become problems

• Identify areas for improvement– Feedback to business and development team

• Ideal move towards DevOps


Sample Results

Maximo Production Monitoring using Sentinel for Maximo


Problem One: Intermittent Slow-Downs


Create Work Order Normally


Create Work Order During Slow Down


The Cause: Poorly Coded (New) Report


Problem Two: Network Issue


Problem Three: Single Maximo Server Degrades


The Cause: Bad User SQL


Trend / SLA Information for Free• Tool should store all results

• Trends will appear quickly

• Empirical SLA information

• Can be easily shared– With management– Publish to Maximo users?

• Justification for future IT spend– Confirmation of benefit post implementation


Response Times per Hour


Summary• Maximo is a critical system

• Performance, stability and scalability problems are serious– Unsatisfied (angry?) users– Prevent business working– Increase costs, possibly lose revenue

• Avoidance (performance testing) is mandatory

• Elimination (production monitoring) is recommended

• There is no longer any justification for a slow or unstable Maximo system


Any Questions?

Upcoming Further Webinars:

• StressTester™ for Maximo demonstration • Sentinel for Maximo demonstration

Check www.genesissolutions.com/

Maximo Performance - A Best Practice Overview Webinar, August 27, 2014

Software

Transcript of Maximo Performance - A Best Practice Overview Webinar, August 27, 2014