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

Improve Maximo Performance
(A CMMS Best Practice Webinar)
Graham Parsons – Product Manager, Reflective Solutions
Bill Thompson – Director APO Marketing Communications, Genesis
Assured Application Page 1 Performance www.reflective.com

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

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

Ähnlich wie Maximo Performance - A Best Practice Overview Webinar, August 27, 2014 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

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