According to analysts and experts in the field, to get the best SAP system performance, enterprises need to choose not only individual servers than can handle their predicted (yet often shifting) business process workloads but also their overall SAP server architecture.
For any size company, choosing
The problem doesn’t have to be easily seen like a server that has gone down -- no, the effect could stem from a bottleneck that constricts a business process over the course of a few weeks so much so that employees are unable to adequately serve a company’s best customer. Lose that customer and maybe a failed application server might have been better after all.
Start with the SAP CPU
According to SAP’s Dr. Ulrich Marquard, the single most important resource for sizing and hardware-focused performance predictions for SAP customers, it’s SAP’s Standard Application Benchmarks site. This free and open resource is designed to help customers and SAP partners find the appropriate hardware configurations for their businesses, he said.
“If you look at the results of the benchmarks, you will see that always the CPU power is the bottleneck,” said Marquard, senior vice president of the technology and innovation platform performance and scalability team for SAP AG.
“First, check how much CPU power is needed, then check other things like memory, network bandwidth, and I/O capacity in such a way that they don’t create an additional bottleneck,” he explained. “These are basically the essentials of the sizing procedure.”
Of course, it’s difficult to extract some enterprise server operating systems, namely, versions of Unix, from the hardware vendors that sell their own proprietary servers. Still, there are a variety of operating system options running on a variety of hardware. How does the choice of operating system affect performance with SAP?
“The differences between the operating systems are very small,” Marquard said. “Today, the differences are more often due to the skill of the people who do the benchmarks than the different operating systems themselves. Often the differences are only 2 to 3 percent … I would be careful to put too much emphasis on the differences in the operating systems.”
Two-tier or multi-tier?
Server architectures could also affect SAP system performance. Are there certain kinds of SAP server architectures that are preferred or that nearly always create excellent performance?
“That’s a very good and very difficult question -- you can have a lot of debate about the best configuration,” Marquard said. “With our prospects or our customers, I have learned that not only performance is a big argument but the total cost of ownership, and that’s about the complexity to set up a system, to monitor a system.
“On the one hand, you can use big boxes and deploy the system so that both the database and the different application servers run on the same physical box -- a two-tier configuration. On the other hand, you can separate application servers from database servers -- which is a multi-tier, typically a three-tier configuration -- where the persistency layer is one tier, the application server is a tier and the database servers are a tier,” Marquard explained.
The key benefits to a multi-tier configuration, Marquard said, is its ability to scale out as a company grows or needs new servers or databases to handle new application server workloads. An unfortunate side effect is that it is generally harder to administer and has increased requirements for the networking communication layers between all the systems.
If you use one larger server that holds both the database and application servers, “then network latency is not a topic, and system administration and configuration is easier,” Marquard said.
In addition, Marquard said that it is important to use servers with multiple cores and avoid using just a single core or CPU. With multiple cores, a server can often handle more simultaneous or near simultaneous requests using a lower CPU utilization rate. “From this point of view, threading more than two to four cores in one system is very good because of the stability in the response times. Or the other way around, to raise the actual CPU utilization is not as much a factor on response time,” Marquard explained.
At the same time, simply throwing an oversized system at a workload doesn’t always create the best response. “If you have too large of a system, then sometimes the memory bandwidth that you have between CPU and memory can lead to a bottleneck. Bigger is not always better, so a compromise is sometimes the sweet spot,” he noted.
Overall, it’s difficult to extract pricing and budget constraints with SAP hardware-related decisions. They simply affect each other. “We often find that CIOs [chief information officers] and IT managers make purchasing decisions based on not what they need, but what they can afford,” said Nathan Weaver, outsourcing services manager for itelligence Inc.
Even when a company makes the correct initial sizing and architecture decision, it can run into trouble.
“IT departments in companies that install SAP are able to get funding to make the initial hardware and infrastructure purchases through initial projects. The problem that many customers face, especially SMBs [small and medium businesses], is that they often find it difficult to get the business leadership to consistently invest in technology. We find that many SMBs later realize that IT is not a core competency,” Weaver said.
“The most common mistake is that people underestimate the full support needed that is required to support an entire SAP landscape,” he added.
Most companies that are in a position to invest in a rigorous and complete enterprise system from SAP want to ensure that their SAP software will run well on their hardware. But how can a CIO be positive when it comes to buy and implement?
“SAP is very much interested in ensuring that the hardware used for running SAP applications is stable, performs well and is embedded in our overall support framework,” said Dr. Torsten Wittkugel, vice president of database and operating system platform development for SAP. “Hence, it is required that customers run their SAP workloads on certified servers which are fully supported by the hardware partner and SAP.”
Based on the operating system, SAP has three basic approaches.
“On Windows, our hardware partners run benchmarks and get them certified by SAP. The certified benchmarks guarantee that the hardware is stable and gives partners and customers an idea for how much workload various servers can take,” Wittkugel said.
“On Linux, SAP requires hardware partners to become members of the SAP LinuxLab. Together with the Linux distributors -- Red Hat and SUSE -- the hardware partner then certifies his servers for SAP applications on Linux,” he added, noting that performance of SAP applications on Windows and Linux are very similar because they run on the same hardware.
“On UNIX, the hardware partner -- HP [Hewlett-Packard], IBM, Sun Fujitsu and others -- certifies their servers for SAP applications,” Wittkugel said.
Turning to the cloud?
Of course, you can’t talk about the hardware landscape without acknowledging the cloud -- public, private or hosted -- as a viable infrastructure choice.
“From the hardware perspective, it is difficult to hit the right size for your company,” Weaver said. “IT managers have a tendency to oversize their environments, assuming that they have enough budget, to account for the unknown. This can lead to overspending and waste to have resources on hand where the potential processing power will go unrealized.”