Blog

Three Steps to Optimizing SAP Application Performance

With each meticulous stroke of the keyboard, each piece of intricate code, each configuration or integration, and with practically everything that occurs as an application comes together, it’s important to think about performance.

As an SAP Administrator I may be tasked with analyzing performance issues and helping developers find the root cause of performance degradation that can occur during development or when the code moves to production. Sometimes the performance issue is something simple that the developer simply overlooked. Sometimes the issue is deeper, such as an issue that is relevant to an SAP Administrator but not necessarily at the top of the priority list for a developer that is focused on their deliverable target date and related acceptance criteria.

Performance issues may not be apparent to the developer until the application moves to production environments where heavy multi-processing results in competition for system resources. Integration with other applications executing in a production environment can also present a challenge.

To optimize performance of an SAP application, I recommend the following steps be taken:

  1. Understand the purpose of the program and why it’s being built.
  2. Execute a trace of the program
  3. Analyze Results

The first step that should be taken is to ask questions to analyze SAP performance issues, such as:

  • Is it a new program?
  • Is it a custom program?
  • Is it an SAP delivered program?
  • Has an OSS note search been conducted to determine if the issue is a known issue resolved by an SAP note?
  • Does the program involve a web service? If so, which?
  • Does the program only read data or write data or both?
  • Has the program been recently modified?
  • What tables are being accessed?
  • Does the program run well in a test environment?
  • Is the program one that is being modified?
    • If the program is a modification of an existing program, additional questions arise such as:
      • When did the performance issue begin?
      • Is the performance issue consistent or sporadic?
      • What time during the day or night does the program execute?
      • Does the performance issue occur also in a test environment or only in production?
      • Has validation occurred to determine the application is used with correct variants or user input?
      • Does the performance issue occur only under specific circumstances?
      • Is it possible the data being operated on has changed?

The second step is to setup and execute a trace of the program. This involves the following steps:

  • Arrange a time to have the program executed in the same manner that results in poor performance of the program (i.e variants, location, launch method, etc.).
  • Using SAP Basis tools watch to see what tables are being hit and watch for patterns as the code cycles through the system
  • Watch for multiple threads in case the application has been configured to use multiprocessing
    • If multiple application servers are part of the production landscape look for related processes that might be launched on different servers
  • Using Operating System tools that monitor memory, cpu and i/o and swap usage to determine if the issue relates to a lack of these system resources
  • Check to see if database lock escalation occurs during the execution using SAP Basis tools or by looking at relevant logs

The third step is to analyze the resulting trace:

  • Determine which relevant SQL statements are consuming the most time
  • Determine which tables are being accessed in the top duration SQL statements
  • Generate an explain plan of the high duration SQL statements and determine if indexes are being used or if full table scans are occurring.
  • Analyze the relevant table(s) and determine their size and what indexes exists for them and when they were last reorganized and statistics run.
  • Compare the where clause of the SQL being analyzed with the index being used to determine if a new index might be warranted.

Additionally, the SAP transactions STAD and ST03N are key performance tools that can provide valuable details on numerous metrics based on user, transaction or program.

In the case of SAP, one must consider the effectiveness of tuning parameters at all 3 levels of the underlying computing infrastructure:

  • Operating system
  • Database
  • SAP

Additionally, performance of network and storage systems must sometimes be considered.

SAP publishes recommended settings for tunable parameters for most major operating systems and popular databases that may have an effect on how well SAP performs. SAP also provides tunable memory buffers that can be monitored and the related tunable SAP parameters are identified making it easier to determine which SAP parameters may be in need of adjustment.

As you can see, when it comes to performance of applications, there is a lot to consider in the analysis and each area above has its own path for mitigation. Performance should be taken into consideration as an application is being designed and coded and performance should also be a consideration during initial testing.

Try to be thorough in building applications with consideration for the end user experience. No one likes to sit and watch the small circle spin or the screen seemly in a dead mode when an application is launched and the enter key is pressed.

Related Blogs
See All Blogs
Abstract tech image
Blog
Apr 15, 2025

Analysis Paralysis in AI Adoption

Learn why endless discussions and the relentless pursuit of flawless data are actually costing you valuable time, insights, and competitive advantage – just like it did for giants like Kodak and Blockbuster.

Read More
Product team at a meeting
Blog
Apr 4, 2025

Don’t Take Product Out of the Equation: How to Nail Your AI Implementation

AI isn't just about the technology, it's about solving real problems and delivering real value. One way to do that is to keep product at the forefront during your AI implementation. Learn more about why having a product-first mindset is so important in this article by Principal Product Strategist Heather Harris.

Read More
Female financial analyst at a computer
Blog
Apr 3, 2025

Navigating AI in Banking and Financial Services: A Risk-Based Rebellion for Leaders

Every shiny AI use case in regulated industries has a shadow: governance, compliance, model risk, ethics, bias, explainability, cyberattack vectors and more. It's not that organizations and leaders don’t want AI, it’s that they’re paralyzed by the political, regulatory, and operational realities of deploying it. Sparq's Chief Technology Officer Derek Perry and VP, BFSI Industry Leader Rob Murray argue we need to change that. Check out this article to learn how to actually ship production AI use cases in regulated environments.

Read More
Product development team working
Blog
Apr 2, 2025

Five Important Questions to Ask Before Starting Your AI Implementation

Creating a lasting impact with AI requires more than just technical output. In this article by Principal Product Strategist Heather Harris, learn five questions to ask before starting an AI implementation so it can deliver long-term business value.

Read More
See All Blogs
noun-arrow-2025160 copy 2
noun-arrow-2025160 copy 2
See All Blogs