# 16 – Understand ongoing performance and optimization options
**What processes and procedures do you put in place to measure performance changes and opportunities for optimization?** Baseline your applications performance requirement from its historical monitoring data and set relevant alerts to inform system administrators when deviations occur. Have procedures in place for system admins to remediate such issues with manual or automated actions.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-16.html)
# Best Practice 16.1 – Have data to evaluate performance
To evaluate the performance of an SAP system and take action in the event performance is suboptimal, monitoring data must be collected for compute, memory, storage, and networking as described in the Well-Architected Framework Performance Excellence guidelines concerning monitoring your resources. As stated in the Well-Architected Framework Operational Excellence pillar, understanding the current state of the system, putting in place key performance indicators, and collecting metrics in a timely manner for diagnosis are crucial for investigating performance issues.
+ Well-Architected Framework [Performance Efficiency]: [Monitor Your Resources to Ensure That They Are Performing as Expected](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/monitor-your-resources-to-ensure-that-they-are-performing-as-expected.html)
+ Well-Architected Framework [Operational Excellence]: [Understanding Workload Health](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**Suggestion 16.1.1 – Gather and store data relevant to performance metrics**
To collect and view relevant SAP monitoring data, you should install and configure the AWS Data Provider for SAP and set up metrics in your chosen monitoring tools that support your SAP workload. Further details on monitoring and additional recommendations are available in the Operational Excellence pillar.
+ AWS Documentation: [AWS Data Provider for SAP](https://docs.aws.amazon.com/sap/latest/general/aws-data-provider.html)
+ SAP Lens [Operational Excellence]: [Best Practice 1.1 - Implement prerequisites for monitoring SAP on AWS](best-practice-1-1.md)
+ SAP Lens [Operational Excellence]: [Best Practice 1.2 - Implement infrastructure monitoring for SAP](best-practice-1-2.md)
+ SAP Lens [Operational Excellence]: [Best Practice 1.3 - Implement application and database monitoring for SAP](best-practice-1-3.md)
# Best Practice 16.2 – Establish baseline performance requirements
Every SAP application has unique performance requirements. Using historical monitoring data helps SAP administration teams understand the baseline performance of these applications, enabling them to identify and understand the extent of any performance changes. Relevant alerts can be put in place to detect anomalies, such as unintended CPU spikes, storage throughput deltas, memory consumption increases, and more complex performance decrements. This monitoring data can be used to further fine-tune performance.
**Suggestion 16.2.1 – Collect and evaluate data that reflects SAP-specific KPIs**
This suggestion aligns closely with additional suggestions in the Well-Architected Framework Performance Efficiency Pillar discussion regarding [resource monitoring](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/monitor-your-resources-to-ensure-that-they-are-performing-as-expected.html).
In addition to this general guidance, SAP-specific KPIs include dialog response time, buffer swaps, used memory. These KPIs might differ based on the type of SAP software and version you are running on. Further detail on KPI and monitoring recommendations is available in this document in the Operational Excellence pillar:
+ SAP Lens [Operational Excellence]: [Best Practice 1.2 - Implement infrastructure monitoring for SAP](best-practice-1-2.md)
+ SAP Lens [Operational Excellence]: [Best Practice 1.3 - Implement application and database monitoring for SAP](best-practice-1-3.md)
# Best practice 16.3 – Identify performance trends using data
After baselines for performance are established, system administrators must monitor trends over time to see if KPIs remain stable within preferred norms. If the performance data indicates a trend toward unacceptable values of the KPI, system administrators can then take steps to avoid or mitigate performance impacts.
**Suggestion 16.3.1 – Conduct regular reviews of SAP system performance**
Periodic reviews of KPIs by system administrators can help identify trends in performance-related data as well as determine which alerts might be most beneficial. These alerts can then be used to automate notifications should the trend continue as well as put in place auto-remediation measures to address the potential performance issue (for example, dynamically changing SAP parameters in response to performance indicators). Examples of KPIs and related trends can be found in SAP EarlyWatch Alert reports, which in some cases can be customized with additional useful metrics. SAP service level reporting can also be useful if you have Service Level Agreements (SLAs) in place for your SAP workloads.
+ SAP Documentation: [Service Level Reporting](http://support.sap.com/slr)
+ SAP Note: [1040343 - SAP EarlyWatch Alert](https://launchpad.support.sap.com/#/notes/1040343) [Requires SAP Portal Access]
+ SAP Note: [1829914 - Customize EWA Reports](https://launchpad.support.sap.com/#/notes/1829914) [Requires SAP Portal Access]
**Suggestion 16.3.2 – Retain historical data to identify trends**
You should retain performance data and associated logs for a predetermined period of time to understand trends in system behavior. Performance tuning of any SAP system will depend on the ability to look back over historical periods of days, weeks, and months to understand what constitutes a performance trend or cyclical performance event. Common events that require retention of data to observe performance impacts include:
+ Month-end and year-end financial processing
+ Increased reporting requirements around business milestones (for example, after a large semi-annual sales kick-off)
+ On-boarding of a large new SAP user population within the business
+ Technology changes, such as infrastructure sizing, database patches, operating system version updates, or SAP software upgrades
# Best Practice 16.4 – Identify and triage performance issues
When key metrics indicate performance is degrading, have a process in place to remediate the underlying cause. Using automation (see the following best practice on dynamic scaling) can reduce the need for manual intervention, but when that is not possible, having an automated alerting process for administrators is vital.
**Suggestion 16.4.1 – Configure performance alerts appropriately**
Follow the guidelines as mentioned in the Well-Architected Framework Performance Efficiency pillar regarding monitoring and alerts, and make use of SAP alerting capabilities where they provide additional capabilities. Additional details are also available in [Operational Excellence] [1 - Design SAP workload to allow understanding and reaction to its state](design-principle-1.md).
+ Well-Architected Framework [Performance Efficiency]: [Monitoring](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/monitoring.html)
+ SAP Documentation: [SAP NetWeaver Alert Monitor](https://help.sap.com/doc/7a827019728810148a4b1a83b0e91070/1610 001/en-US/frameset.htm?frameset.htm)
**Suggestion 16.4.2 – Automatic remediation of performance incidents**
While the management of performance incidents involves the best practices on operations detailed in the Well-Architected Framework Operational Excellence pillar, the proactive detection and automated remediation of potential performance impairment can prevent deepening a performance problem and can improve the end-user experience. When automated processes for mitigating a performance issue are not possible, having a detailed runbook in place on how the operational team should respond to a performance issue can accelerate the response to a performance incident.
+ SAP Lens [Operational Excellence]: [Best Practice 1.8 Use automated response and recovery techniques to react to monitoring alerts](best-practice-1-8.md)
+ Well-Architected Framework [Operational Excellence]: [Best Practices: Operate](https://docs.aws.amazon.com/wellarchitected/latest/framework/oe-operate.html)
# Best Practice 16.5 – Scale to meet performance demands
One of the primary benefits of operating workloads in AWS is the ability to increase or decrease the compute capacity and change the storage performance characteristics to match the performance required for the use case. For SAP workloads, use dynamic scaling where applicable to avoid performance bottlenecks. Scenarios where dynamic scaling is not possible, such as scaling out an SAP HANA database cluster, use a manual deployment process.
**Suggestion 16.5.1 – Reactively scale SAP workloads**
In response to dynamic changes in workload performance requirements, scale your SAP resources accordingly. Where possible, use automation to scale in or out, but when that is not an option (such as scaling up a database instance), have a process in place to do so manually. Consider:
+ Adding or removing application server capacity or changing instance sizes as required to meet demand
+ Changing SAP parameters to redistribute virtual resources programmatically
+ [Modifying storage type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html) (for example, Amazon EBS `gp3` to `io2` or vice versa in AWS), where applicable, to optimize storage performance
+ AWS Documentation: [Request modifications to your EBS volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html)
**Suggestion 16.5.2 – Schedule scaling for predictable SAP workloads**
Whether in an automated or manual fashion, scaling an SAP workload up or down based on predictable performance patterns is advisable. For instance, when month-end financial processing on an SAP ECC system leads to a predictable 20% increase in processing requirements on application server instances, system administrators can proactively increase the number or size of application servers, then scale-in the number of instances when the usage predictably decreases.
# Best Practice 16.6 – Develop mechanisms for simulating production load for analysis purposes
Having a clone of production data in a test system allows system administrators to simulate production SAP workloads and conduct vital performance tests, such as stress and volume testing. This type of testing can help identify potential performance bottlenecks and prevent performance issues from occurring in a live production environment.
**Suggestion 16.6.1 – Define performance sensitive activities**
Evaluate which transactions, reports, and operational activities could have an impact on your business if they do not meet peak load requirements or time-critical thresholds. For example, an overnight batch job which must complete in five hours, or a customer-facing transaction accessed concurrently by thousands of users during a quarterly business peak. Document and agree on the measurement approach, KPIs, and success criteria for these workload activities.
**Suggestion 16.6.2 – Create an automated test approach for key activities**
If required, develop a test strategy to confirm that your SAP workload performance benchmarks are met. Evaluate how test landscapes and tools can enable a repeatable suite of tests to measure the impact of operational activities, change releases and major patching on the performance of your workload.
# Best Practice 16.7 – Continually optimize sizing and configuration based on performance data
Review performance metrics on a regular basis outside of your incident response process. By doing so, you can discover system components that are undersized, oversized, or no longer used at all. A regular performance optimization cadence should be established for your SAP workloads, focusing on right sizing your system components for real user load. This activity will improve user experience, eliminate unneeded aspects of your architecture, and help improve both the cost effectiveness and resilience of your workload.
**Suggestion 16.7.1 – Perform regular architecture right sizing with historical performance metrics as a guide**
Regularly review your SAP workload for opportunities to right-size its components. Consider whether storage, compute, network, and supporting services need to be increased or decreased to better fit your business performance requirements.
For further information, refer to the following resources:
+ SAP Lens [Cost Optimization]: [Best Practice 20.5 - Review usage for opportunities to optimize](best-practice-20-5.md)
+ SAP Lens [Operational Excellence]: [Best Practice 4.4 - Perform regular workload reviews to optimize for resiliency, performance, agility, and cost](best-practice-4-4.md)
+ AWS Documentation: [Right-Sizing](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/)