Think of an expensive wine... let's take Petrus. Would you really want to have it served to you in a tea-stained mug? Probably not, although you may answer that if someone's giving you Petrus you wouldn't care what it’s served in! But if we're honest, the experience would be 'sub-optimal'. The same applies to SAP HANA. You've made a considerable investment in the application, so why try to save costs by running your application tier on old hardware? It's not only the experience but more importantly the performance that will be suboptimal.
SAP HANA changes how you need to architect your application landscape if you want to ensure you experience the results you’ve read about. Believe me, the hype around HANA isn’t mythical. HANA is at the very heart of my working life. Implementing it at many large companies and seeing the results first hand hasn’t just corroborated the results I saw back in the SAP labs six years ago, it also evidences SAP’s very bold claims.
Chasing the bottleneck
Let’s take a look at SAP BW on HANA, although the same rings true for Suite on HANA, S/4HANA or any other landscape which includes HANA and an ABAP stack.
Performance tuning an SAP system is not dissimilar to performance tuning any other system. You perform the analysis on the system and locate the bottleneck, then you adjust that bottleneck and reassess. It’s a very iterative process, moving the bottleneck from one part of the system to another, until you’re satisfied with the level of performance you’re getting.
The bottleneck could be in any number of places including: the hardware layer, virtualization layer, operating system layer, software layer or functional build layer. Of course, this is applicable to all areas of your landscape; for example, the database server and the application server. Finding that bottleneck and removing or reducing it simply moves the bottleneck to somewhere else. This is why performance tuning is often referred to as ‘Chasing the bottleneck’.
The more complex or distributed your environment is, the more places you have to go hunting and the harder it is to find.
Where is the bottleneck with SAP BW on HANA?
Most of the time, when migrating to HANA the bottleneck in the system shifts to the BW application servers. A non-optimised functional build or poor ABAP code could result in BW asking HANA a silly question, and thus putting the bottleneck in either the database or functional build category. However, we’ll assume that the functional build is good, the ABAP is optimised and the bottleneck, as expected, has been shifted to the application tier hardware.
How should I optimise my application tier to avoid it being the bottleneck?
When you execute something in an ABAP stack, whether it be a transaction, report, functional module or even a third party tool connecting into BW, the connection and ‘work’ occurs within a work process. Each system will have a specific number of work processes defined: split between dialog processes and background processes.
The work process itself is single threaded. This means it is constrained to a single CPU core or thread. As an example, if your application tier has 16 CPU cores and you have 1 user executing a really heavy report, the maximum CPU usage on the entire system will be 6.25%. If there were 16 concurrent users, all executing heavy reports at exactly the same time, then the CPU usage of the application server could hit 100% CPU.
Therefore, it’s vital that the CPU inside the application server can burst to good speeds to ensure that each single threaded execution goes as fast as it can.
Modern Intel or POWER CPUs can provide up to 3000 SAPs (SAP’s method of benchmarking performance) per core. Older CPUs, some AMD CPUs and CPUs which make up platforms not designed for this type of workload, such as Intel Itanium, deliver 1000-1200 SAPs per core.
This means by simply replacing your application tier or supplementing it with something modern and suitable for the workload, you could increase the performance of work process constrained tasks by up to 3x.
If you want to experience the full power of HANA, don’t forget about the application tier hardware when purchasing your shiny new HANA appliances. The cost of new servers for the application tier is a fraction of the cost of a HANA appliance and just as important.
When purchasing those servers, to mitigate the risk of your application tier hardware being the bottleneck, use hardware that has an appropriate CPU and thread performance for your HANA application tier processing. That means no AMD Opteron, no Intel Itanium or anything else that delivers less than 2300 SAPS per core. Don’t get me wrong, these have their place in landscapes. The Itanium when coupled with HP-UX is fantastic for business critical workloads and has some amazing availability and virtualization features. If you already have it in your landscape and want to keep the availability features, you can always just put the single points of failure on it, such as ABAP System Services (ASCS) and then have fast, modern hardware to do the grunt of the work in the form of application servers.