Quick and easy performance analysis of ABAP SystemsChris Kernaghan

Principal Consultant

2

Why is performance analysis so painful

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

OpentextWindows 2012SQL Server 2012

CRM Windows 2012SQL Server 2012

ReportingAd-hoc reportingusing Live office & web Intelligence BObj

General LedgerPayrollControllingAP/AR

Archiving

Data servicesExtractTransformLoad (ETL)

Integration engine

UserPresentation layer

SAP PI

SolutionMgr.

BW 7.4Windows 2012

PI 7.4Windows 2012SQL Server 2012

NW Portal 7.4Windows 2012SQL Server 2012

Business Objects 4 & Data ServicesWindows 2012SQL Server 2012

Business object explorerDashboard and Web intelligence

TREX 7.10Windows 2012

Solution Manager 7.1 SPS 9Windows 2012SQL Server 2012

Business Objects 4.1Windows 2012SQL Server 2012

SAP ECC 6 EhP 7 Windows 2012SQL Server 2012

SAP Portal

BOdsBObj

OpenText

TREX

CustomerRelationshipManagement

BW

CRM

ECC

MDM

NW 7.4 ABAP MDMWindows 2012SQL Server 2012

No plans to monitor

Some monitoring

Monitors configured

4

Scenario 2 – Project system

ReportingAd-hoc reportingusing Live office & web Intelligence BObj

General LedgerPayrollControllingAP/AR

Integration engine

UserPresentation layer

SAP PI

SolutionMgr.

BW 7.4Windows 2012

PI 7.4Windows 2012SQL Server 2012

NW Portal 7.4Windows 2012SQL Server 2012

Solution Manager 7.1 SPS 9Windows 2012SQL Server 2012

SAP ECC 6 EhP 7 Windows 2012SQL Server 2012

SAP Portal

CustomerRelationshipManagement

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

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!

7

Step 3 – Define measuring strategyOnce 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

8

Step 3 – Define your actual measuring strategyResolving performance issues relies on 3 things1. Recording information to be used in resolving the issue2. Managing your stakeholders to ensure they don’t get in your way3. 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 reasoning4. Network – Does the problem still occur when run on the server5. Storage – Are you on dedicated SAN for SAP with no other issues6. Database – No other transactions or queries have any issues7. User – Repeat the steps for reproduction

Once you know what you are measuring – you have to pick your tools

9

Example – monitoring tool /SDF/Mon

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

12

Demo

1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103 109 115 121 127 133 139 1450

20,000,000

40,000,000

60,000,000

80,000,000

100,000,000

120,000,000

140,000,000

160,000,000

Used Memory

Measurement Number

Used

Mem

ory

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

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

15

Demo

16

Step 6 – Actioning the outcome of your data

There are many ways to visualise your data 1. Excel2. Lumira3. Business Objects4. 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!

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