Best Practices for Achieving High Performance and Scalability in Your System Landscape

The demands on today’s IT organizations have never been higher. Companies are looking to IT for so much more than internal back-office services — IT must become a strategic partner of the business, providing innovative solutions in customer and partner interactions as well as product and service development. As such, IT management has become much more challenging.

Consider today’s system landscapes. Instead of one single system running an SAP ERP application, there are now multiple systems integrated by the flow of business processes, spanning different business domains, and involving different SAP Business Suite applications, third-party products, and middleware. CIOs and enterprise architects must secure high performance and scalability across it all.

Then think about data and process consistency. It’s not provided by one integrated database design, but rather achieved through messaging, data, and user interface (UI) unification. And it is harder to keep track of the entire integrated IT landscape, particularly if an incident or problem occurs. Issues with the performance of business-critical applications can cause an organization’s business performance to deteriorate. Key business processes supported by slow or not readily available applications can cause revenue loss, a decline in customer satisfaction, lowered employee productivity, and jeopardized brand reputation. The stakes are high.

What’s more, organizations are looking for new ways to transform their business offerings and improve their performance by developing new, unique approaches to their business. Several related hardware trends have led to a paradigm shift in database design recently, resulting in the development of in-memory databases such as SAP HANA that are setting new standards in data management performance. And with companies using more cloud and mobile applications, their landscapes are further extended — and still must deliver the performance that consumer-oriented users expect.

So how can IT teams ensure that their SAP software landscapes are consistently high-performing and reliable, to support all of these business demands? Directed specifically toward enterprise architects, this article provides guidance and best practices on some specific performance and scalability characteristics that are fundamental to tackling these challenges.¹

Key Performance and Scalability Indicators

First, it’s important to understand the most important indicators for performance: response time and throughput.

Response time is the time from when a user triggers an interaction until the user sees a UI that is ready for the next input. Expected response times vary with the perceived complexity of a task. In the same way, the user’s behavior varies if his or her response time expectations are not met. Users make assumptions about the complexity of each request and, based on these assumptions, they grant the system a corresponding amount of time to process their request. The time users allow for the system depends strongly on their perception of the complexity of the task. Achieving sub-second average end-to-end response times is a target for interactive applications that process business data of normal volumes. Sub-second response times are standard and in line with studies on perceived performance conducted by our usability team.

High throughput is generally more relevant for background processes. Companies expect a system to behave in a predictable manner when throughput increases. This means that a system must always run optimally, even in high-load situations in which several million document line items are processed per hour.

The precondition for high throughput is having software and hardware that are scalable. A scalable software system can predictably handle increasing amounts of work and should be easily extendible to process more tasks. For example, if the load increases by a factor of 10, a well-scaling software system requires at most 10 times the resources, preferably less. Scalability involves two aspects: linearity with the number of business objects and concurrency (processing with parallel jobs or concurrent users).

Only when an IT system is scalable is it possible to perform adequate hardware sizing. The purpose of hardware sizing is to determine the hardware resources necessary to process performance-critical business processes, thus preventing hardware resources from becoming bottlenecks.

Implementation Scenarios: Important IT Landscape Planning Considerations

Equipped with this understanding of performance and scalability indicators, let’s consider an example. To improve a key business process, your organization decides to implement a new piece of software. Once you’ve determined the specific software packages needed, you should then decide the layout of your system landscape as part of the overall  landscape design and architecture — in other words, you decide how many servers you require and how you want to use each of these servers.

For this step, you have to consider many aspects and landscape rules to decide if you want to bundle functions inside a server or distribute them to different servers. Dependencies among usage types, interoperability of hubs, IT landscape maintenance and operation, and security play an important role in determining a landscape layout that fits your individual requirements.

From here, it’s important to plan for the following considerations: system availability, network and WAN performance, virtualization, and sizing.

System Availability

Critical business and operational systems must be highly available at all times, which involves having a disaster plan. A high-availability concept must be discussed from a business perspective first. It is impossible to properly design a system without a definite understanding of the business’s availability requirements.

Network and WAN Performance

Distributed landscapes result in an increasing number of users connected to a central system from dispersed sites with varying degrees of available network bandwidth and latency. User access takes place through a local area network (LAN) and a wide area network (WAN). The objective of sizing is to avoid a performance bottleneck caused by insufficient network bandwidth and ensure reasonable response times.

Network bandwidth is a resource shared by many users. If the available bandwidth is exhausted, the network becomes a bottleneck for all network traffic. Interactive applications suffer the most from overloaded networks. Concurrent requests from multiple users can interfere with each other, resulting in varying network response times. Other applications that compete for available bandwidth may also influence response time.

Keep these points in mind when you add up all of the traffic as you plan your network bandwidth. Latency time depends on the number of network hops (nodes) and the propagation time required for a signal to get from A to B, between and on these nodes. Today, network latency is the most significant parameter in poor response times.

Even in a metropolitan area network (MAN), the database and the application server should be physically located in the same data center.

Virtualization

More companies are turning to virtualization to reduce IT costs, decrease complexity, and improve flexibility. For example, virtualization allows you to run several operating systems and applications at the same time on a single computer and flexibly balance applications. This helps reduce TCO through the economical use of servers.

From a performance perspective, it is essential in a virtualized environment not only to measure the system load within the single system but also to link the measurements to the overall load situation of the physical server or the entire storage system. Each system in a virtualized environment might be influenced by its neighbor systems, so that bottleneck investigations of a single system always require sanity checks of the other systems. Because resources are shared in virtual environments, virtual machines, though isolated from each other in terms of memory and access, can nonetheless affect each other in terms of performance. For CPU sizing in a consolidated environment, which can be achieved by virtualization, you have to consider the peak CPU consumption for the consolidated sum of all systems (see Figure 1). Note that SAP software systems are typically sized for peak utilization.

Sizing

In general, sizing means translating business requirements into hardware requirements to run software solutions and applications.² A mathematical model and procedure can help predict resource consumption based on a reasonable number of input parameters and assumptions (see Figure 2).

Sizing key performance indicators (KPIs), including CPU, memory, hard disk, and network, help explain how an application uses hardware resources. Each hardware resource is associated with a lower or higher initial cost and maintenance cost and is part of the customer’s TCO.

Best Practices for Development Projects

Not all unique business requests can be covered by standard software. In these cases, you can extend your software so that it addresses your particular needs and interests — and this often involves development work.

Programming for good performance means using critical resources reasonably, keeping response time to a minimum, taking network communication aspects into consideration, and producing software that is scalable.

Planning Performance Targets

In the planning phase of your development, KPIs should be clearly defined. Good KPIs should reflect the performance both from a user and a system point of view, and should be measured accurately. In a KPI-focused approach, the question “Which performance characteristics should be defined as KPIs?” is much more important than meeting concrete KPI values.

Performance-Optimized Programming

Many performance issues cannot be solved by simply fixing an error in the software — often these issues are caused by inappropriate design decisions made in the software architecture. Performance design patterns specify target behaviors and design rules for software components and interfaces while allowing a high degree of freedom for the implementation.

An SAP business application generally consists of three layers: the persistence layer, the application layer, and the front-end layer. Relational database systems are typically used in the persistence layer, and the data accesses are executed by SQL statements. While the persistence layer has to ensure data consistency under highly concurrent data accesses, the application layer carries out the CPU-intensive processing of business logic. The application layer of a large software system is typically built up by a load-balanced cluster of application servers, which scale in CPU and memory while providing high availability. The front-end layer represents the UI, typically running on PCs, connected by a LAN or WAN to the application servers and providing high usability and productivity to end users.

Figure 3 outlines some important KPIs and design patterns that developers could carry out in performance tests. You could also use these KPIs for quality check points and regression tests run by quality teams. Remember that the goal of testing is to find as many functional and performance issues as possible by executing a limited set of specified test cases.

Let’s look at some of these KPIs and design patterns in more detail:

• Average end-to-end response: End-to-end response time includes the server response time, network time, and front-end rendering time. The traditional approach of basing performance testing, analysis, and optimization on response time tries to break down end-to-end response time into times spent in individual software components, and to identify the root causes. The optimization activities try to reduce or even eliminate any identified issue.
• Network round trip per user-interaction step: A user-interaction step has at least one synchronous communication cycle, which is a network round trip between the front end and the application server. It is triggered by a user action and typically results in a new UI screen. Because network performance is mainly defined by latency time and bandwidth, a minimal number of network round trips and minimal transferred data volume will optimize the network time. You should minimize the number of network round trips — try to keep it down to two per user-interaction step — and the volume of data transferred.
• Linear dependency: The scalability of a large application can only be achieved when the resource consumption depends at most linearly on the number and size of processed business objects. Otherwise, the resource requirements will quickly exceed any possible limits and result in unpredictable increases in response time.

Outlook

The key concepts and recommendations included in this article will help enterprise architects ensure the performance and scalability of today’s complex system landscapes. Looking ahead, nontraditional data types and external data sources will continue to play a large role, and organizations will need to focus on them. Companies must manage the rapid growth in data volume and complexity while exploiting data to adjust operational processes, strategies, and business models more quickly than the competition.

SAP HANA is already helping businesses reach these levels of productivity by addressing important aspects of big data — like fast access to and real-time analysis of very large data sets — that allow man-agers and executives to understand their business at “the speed of thought.” SAP HANA enables true real-time OLAP on an OLTP data structure. This helps dramatically improve the performance and keeps TCO to a minimum.

For more information on achieving high performance landscapes, visit https://service.sap.com/performance or https://scn.sap.com/community/performance-scalability.

¹ To learn more about performance and scalability characteristics in SAP landscapes and best practices, view the CIO guide “Securing High Performance and Scalability in Customer System Landscapes” at www.sap.com/bin/sapcom/en_us/downloadasset.2014-01-jan-21-22.cio-guide-securing-high-performance-and-scalability-in-customer-system-landscapes-pdf.bypassReg.html. [back]

² For more information on sizing methods and tools, see www.service.sap.com/sizing. [back]