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: Understand the purpose of the program and why it’s being built. Execute a trace of the program 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.