How to perform quick and dirty performance analysis and use technology like Lumira to visualise the output.

1. Quick and easy performance
analysis of ABAP Systems
Chris Kernaghan
Principal Consultant

2. Why is performance analysis so painful
2
Performance problems are the bane of any Systems administrators life
• Helpdesk calls are woefully short of information required
• Issue is intermittent
• Issue is a high priority and forces people to run around like headless
chickens
• Involves lots of moving parts which use different monitoring systems
• Monitoring software is not configured correctly

3. Scenario 1 – Production System
3
Opentext
Windows 2012
SQL Server 2012
CRM
Windows 2012
SQL Server 2012
Reporting
Ad-hoc reporting
using Live office & web Intelligence BObj
General Ledger
Payroll
Controlling
AP/AR
Archiving
Data services
Extract
Transform
Load (ETL)
Integration
engine
User
Presentation
layer
SAP
PI
Solution
Mgr.
BW 7.4
Windows 2012
PI 7.4
Windows 2012
SQL Server 2012
NW Portal 7.4
Windows 2012
SQL Server 2012
Business Objects 4
& Data Services
Windows 2012
SQL Server 2012
Business object explorer
Dashboard and Web intelligence
TREX 7.10
Windows 2012
Solution Manager
7.1 SPS 9
Windows 2012
SQL Server 2012
Business Objects
4.1
Windows 2012
SQL Server 2012
SAP ECC 6 EhP 7
Windows 2012
SQL Server 2012
SAP
Portal
BOds
BObj
OpenText
TREX
Customer
Relationship
Management
BW
CRM
ECC
MDM
NW 7.4 ABAP
MDM
Windows 2012
SQL Server 2012
No plans to monitor
Some monitoring
Monitors configured

4. Scenario 2 – Project system
4
Reporting
Ad-hoc reporting
using Live office & web Intelligence BObj
General Ledger
Payroll
Controlling
AP/AR
Integration
engine
User
Presentation
layer
SAP
PI
Solution
Mgr.
BW 7.4
Windows 2012
PI 7.4
Windows 2012
SQL Server 2012
NW Portal 7.4
Windows 2012
SQL Server 2012
Solution Manager
7.1 SPS 9
Windows 2012
SQL Server 2012
SAP ECC 6 EhP 7
Windows 2012
SQL Server 2012
SAP
Portal
Customer
Relationship
Management
BW
CRM
ECC
No plans to monitor
Some monitoring
Monitors configured

5. Step 1 – Identify your problem
• Establishing that you even have a performance issue is a vital step.
• With multiple connected systems working out where the problem lies
is difficult
• ECC -> CRM -> TREX
• Web Dispatcher -> Portal -> ECC
• HCP -> Cloud Connector -> ECC
What can you do to help establish that you have an issue
• How many calls have been received
• Has there been any changes implemented in the last 24hrs – large or
small
• Look back over your daily checks to establish if anything jumps out at
you
5

6. Step 2 – Establish the width of effected area
If you have a performance problem, it is essential to establish how
widespread it is.
• The helpdesk have to record several essential pieces of information
from every call
• The user and username of every affected user calling
• The time of the incident and approximate duration of the incident
• The system being used which showed the problem
• The transaction or application in use at the time
• The location of every user logging calls
• The steps undertaken to reproduce the error
• Eliminate the most common causes of issues first – ASAP!
6

7. Step 3 – Define measuring strategy
Once the most common causes of performance issues have been deprioritised –
the next step is working out what needs to be measured.
• Infrastructure layer
• Network – bandwidth utilisation
• Storage – disk I/O
• Server – CPU, Memory
• Database layer
• Database caches – Cache hit ratios
• Indexes - fragmentation
• Parameters - deprecation
• Application layer
• User parameters – Selection criteria
• User presentation layer
• Location – network latency
7

8. Step 3 – Define your actual measuring strategy
Resolving performance issues relies on 3 things
1. Recording information to be used in resolving the issue
2. Managing your stakeholders to ensure they don’t get in your way
3. Prioritising your resources to the most likely areas to resolve the
issue – The biggest pay off for the least amount of effort
In order to do this – it is necessary to make choices which are most likely
to identify where your issue is. De-prioritising places is relatively easy by
using reductive reasoning
1. Network – Does the problem still occur when run on the server
2. Storage – Are you on dedicated SAN for SAP with no other issues
3. Database – No other transactions or queries have any issues
4. User – Repeat the steps for reproduction
Once you know what you are measuring – you have to pick your tools
8

9. Example – monitoring tool /SDF/Mon
9

10. 10

11. Step 4 – Dealing with your data - Cleansing
• Following the last step the tools you have chosen to record your
system performance have been running for a period of time.
• The next step is to take the data from those tools and put them into a
usable format
• Different scales for recorded objects – seconds to milliseconds
• Different time scales – different tools record at different intervals
• Adding columns – calculating % free memory
• Working out boundary values – Min, Max, Median
• Establish what you are measuring your system against
These are all necessary to ensure valid comparisons of system objects
11

12. Demo
12
0
20,000,000
40,000,000
60,000,000
80,000,000
100,000,000
120,000,000
140,000,000
160,000,000
1
6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
101
106
111
116
121
126
131
136
141
146
UsedMemory
Measurement Number
Used Memory

13. Step 4 – Dealing with your data - Grouping
Once you have cleansed your data, you have to put it into buckets which
will tell the story of the elements you want to investigate
This makes it easier to visualise and to identify the performance changes
which will lead you to resolving your performance problem
13
User
Free WP Used Memory CPU Idle Sessions
Server
CPU User CPU Sys Paging Used Memory
Application
Free WP Sessions Act WP Logins

14. Step 5 – Visualising your data
Visualising your data output is a good way of understanding your issue
and the causes of it
14

15. Demo
15

16. Step 6 – Actioning the outcome of your data
There are many ways to visualise your data
1. Excel
2. Lumira
3. Business Objects
4. D3.js
Chose whatever works for you, but make sure it highlights the problem
areas in an easy way to understand – you will be communicating this to
non-technical people.
Draw up a remediation plan to resolve the issue – without this you have
a reason for the issues but not an solution!
16

17. Conclusion
• Performance analysis is painful – but it’s of your own making
• Murphy’s law always applies to the timing of a performance issue
• Use reductive reasoning to de-prioritise areas to look at
• For intermittent issues do not waste time with best practice
guidelines, baseline the system against itself
• Manage your stakeholders carefully
• Visualisations without actions are just pretty graphs – you have to
have a plan to fix the issues not just find them
17