Upload
chris-kernaghan
View
350
Download
2
Embed Size (px)
Citation preview
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