SAP performance issues can be extremely complex and painful – for users, for administrators, and for IT teams alike. My colleagues and I know this first-hand as our experience as Dynatrace Guardian Consultants gives us unique insight into some rather difficult performance challenges. The seemingly simple question – “Why are users experiencing poor performance?” – evolves into many more. Is it all users, or just some? Is the problem location-dependent? Are there certain transactions at fault, or is everything slow? Is there a time-of-day pattern? Is the reported problem real, or largely user perception? Answering these questions demands transaction-level visibility of the end-to-end application delivery chain – from the user, across the network, through the data center to the back-end databases; for this, we rely on Dynatrace Data Center Real User Monitoring (DC RUM), with its industry-unique SAP analysis module.
David’s Growing Problem
David is an application Service Delivery Manager for a multi-national agricultural company, responsible for delivering a range of application solutions to internal employees around the globe. SAP takes a particularly high priority given its impact on business results, in particular the Business Warehouse module. One of David’s more immediate goals for implementing DC RUM was to be able to be alerted to performance problems before users complained, and to understand the business impact of these problems to help him prioritize his efforts with business results in mind. As we’ll see, these goals were realized almost instantly.
SAP Dispatcher Delays
Whilst everything can look great on the surface, especially if the phones aren’t ringing, users can still be suffering. Figure 2 below shows a high-level summary of SAP performance for the last hour, with 228 slow operations (transactions) affecting about 40 of the 211 active users.
Drilling one level deeper, we find a handful of SAP Dispatcher servers associated with the slow operations. One of these shows application performance at 92.4%, well below the defined acceptable threshold of 98%. Average transaction response time for this server is almost 5 seconds.
Drilling down even deeper, we can see a list of individual transactions executed by a single user – who hasn’t yet complained – served by this SAP Dispatcher server. At this level, David is able to proactively address performance issues before the user calls. He is also able to verify a user’s complaint via the helpdesk – did the problem occur as reported? And by DC RUM’s unique visibility into the number of affected users, the types of transactions experiencing problems, and the severity of the performance degradation, David can respond with business interests in mind.
Maybe This Time it is the Network
The breakdown of operation times indicates that most of the problematic delays are attributed – automatically – to the network. While DC RUM offers report-driven packet capture (or back-in-time retrieval) for those cases that require more detailed proof, David felt confident that the servers were performing normally, and that the isolated network fault domain was worth investigating without further analysis. With a quick view into a traffic overview report, David noted an unscheduled (or at least unanticipated) major roll out of a new anti-virus software package; this was being distributed to users at the site in question. David postponed the distribution to a less-critical time of day, resolving the critical SAP issue.
DC RUM’s ability to combine transaction visibility, username recognition, and a broad view into all application traffic traversing the network gave David the exact insight he needed to quickly understand and rectify the problem. This transaction-centric approach to AA NPM offers new opportunities to collaborate effectively with business and development teams, in ways that are not otherwise possible.