SAP Sizing

SAP Sizing: More than just a number.

Introduction

It is common knowledge in IT that hardware gets smaller. The same cannot be said for workloads. The need to record, retrieve and analyse information is growing at a tremendous rate and that is reflected in the growth of IT systems that perform these workloads. SAP is no exception. Estimating growth as well as understanding your current workload are some of the important elements to sizing a new SAP system. Correct sizing is the happy place between systems that constantly seem to be on the brink of grinding to a halt and systems that perform like a dream but only run at 15% utilisation. When systems are undersized and struggle to perform the end user experience is poor, and this can lead to user wide negativity towards the solution. When systems are oversized, the end users may be happy but you have needlessly overspent on hardware and in most cases software too. So firstly, you must ensure that the sizing number you get is the right one. These articles do not attempt to help you get to that number. This article is the first in a series that aim to assist you once your new system has been accurately sized. These articles are concerned with SAP's benchmarking known as SAPS. The articles will explain how the SAPS benchmark is calculated and how to interpret the benchmarks when comparing hardware and virtualisation options.

For guidance on SAP sizing you should refer to your SAP consultant or try these links.

Vendor specific links.

Once you have gathered all the required information and processed it through the SAP Quicksizer, you will have a number of results. These results are normally:

SAPS (CPU), Memory, DB Memory, App Memory and Disk DB (MB).

This series of articles is wholly aimed towards the figure quoted as SAPS.

In the beginning

SAP formalised the benchmarking of systems with the SAPS benchmark in 1997. According to SAP's benchmark the first system to be awarded a SAPS benchmark score was a Compaq Armada 7730 MT Laptop featuring a 166Mhz Pentium MMX processor with 144MB Memory. The system was running Microsoft NT4 and Oracle 3.1G. The following graphs have been compiled using benchmark data available on 21/1/2010 and shows how the systems being submitted for benchmarks changed from 1998 to 2009.

In the late 1990s multicore processors did not exist, therefore the graph represents the average number of physical processors for pre-multicore systems. The graph shows a rather slow increase in average number of cores being used in systems until the end of 2007. 2008 and 2009 see large rises in the average number of cores in benchmarked systems with an average of around 35 cores in 2009.

The average clock speeds of systems tested by SAP show a steady increase from 1997 to 2005. Since 2005 the clock speeds seem to have plateaued. However, the previous graph shows that the number of cores has increased so therefore we would imagine that overall system performance to also increase.

Average main memory size has seen huge increase since 1997. The 1997 the average amount of memory in benchmarked systems was 1.7GB. In 2009 the average was 174GB, over 100 times more than in 1997. In addition 2008 and 2009 saw the largest rises in memory use which seems to be in line with the rise of the numbers of cores.

This final graph shows that the average benchmark result for systems submitted to SAP. Like number of cores and amount of memory, the average benchmark result has seen steady growth from 1997 to 2007 and large rises in 2008 and 2009.

The following conclusions can be drawn from this data. As expected the average benchmark result of systems submitted to SAP has increased over time. Multicore technology and the large increases in memory seem to have increased performance more than the improvements in CPU clock speed.

Although in the majority of cases SAP workloads are growing, it is not likely that the average SAP workload has seen the same explosive growth demonstrated in the average benchmarked systems in 2008 and 2009. So is there a need for such large systems? Some SAP customers may require a single SAP instance with 256 cores and terabytes of memory but it is more likely that customers running these large systems are using them for virtualisation (much more on this in later articles). Virtualisation allows multiple SAP applications and instances to run on the same hardware without the need for tens or in some cases hundreds of individual servers.

The SAP software model allows 'Scale up': multiple instances virtualised on large systems and 'Scale out': spreading the load of single systems across multiple smaller systems. Both approaches have their positives and negatives and will be covered in later articles. When the 'Scale up' vs 'Scale out' argument is added to the hundreds of different SAP certified benchmarks it becomes apparent that choosing hardware for a new solution is not just a case of looking through the benchmark figures and choosing a close match from the hardware vendor you usually buy from.

The next article in this series explains how the SAPS benchmarking is carried out and what information is available from SAP about each benchmark. In addition there will be information regarding the OS's and databases that each of the major hardware vendors chose when submitting their systems for certification.

Speed up your SAP with Centiq SAP Options.

Centiq will be IBM's single UKI route to market for SAP HANA and we will assist in Sizing, Appliance deployment. Maintenance and ongoing support thus providing an in-country deployment and support model.

* New * SAP HANA overview: Click here

* New * SAP HANA Appliance options Click here

View our SAP BW Accelerator page: Click here

Speak to one of our SAP Expert Consultants by calling us on 0115 951 9666, or leave your details above and we'll contact you right away.