GRC
HR
SCM
CRM
BI


Article

 

Targeted Methods and Tools for Right-Sizing Your Hardware Landscape

by Susanne Janssen | SAPinsider

January 1, 2006

by Susanne Janssen, SAP AG SAPinsider - 2006 (Volume 7), January (Issue 1)
 



Susanne Janssen,
SAP AG

In IT and business, size matters. In hardware terms, it matters how much money you have to lay down for the data center layout, electricity, space, cooling, storage devices, network cables, and so on. But sizing your server landscape is not just about the hardware, either; it is the process of translating business volume requirements into hardware requirements. Once you know the maximum hardware requirements based on sizing KPIs — including CPU time, disk size, memory size, and network bandwidth — only then can you choose your hardware and decide whether it makes sense to install two servers in one box, two databases on one server, two solutions in one database or parallel databases, multiple blades, and so on. Sizing results can help you determine failover and high availability strategies, as well.

SAP provides a number of tools and methods to assist you in the complex process of acquiring the right sizing results for your company. This article introduces you to some of these resources, along with some examples from actual sizing projects.

Set the Stage for Sizing

The required hardware to run any business application depends on a variety of influences — including customizing, system parameter settings, usage, and custom developments — that may lead to sizing projects of several months' length. SAP customers often find that industry and legislative requirements also play their part in the definition of business requirements, such as information lifecycle strategies that require online access to data for as long as 100 years. Ignoring or glossing over these sizing influences and simply adhering to SAP standard recommendations could lead to an insufficient hardware landscape, one that's either too small or much too large.

Sizing is an iterative process, meaning that you should be prepared to cycle through sizing activities several times — both before going live and after your solutions have gone into production — to achieve conclusive results. But the importance of sizing cannot be overstated; with accurate sizing, achieved through the tools and methods SAP provides, you can collaborate with hardware vendors to arrive at the right system design that most efficiently meets your current business and performance requirements, and that also reliably scales over time.

Gauge Your Sizing Requirements

Since SAP provides standard software applications that often cross industry boundaries, and because each company has a unique set of system needs, the possibilities are endless when it comes to different business uses and thus sizing KPIs. In a typical sizing project, it takes a series of evaluations and tasks to get accurate sizing results. For example, you'll need to:

  • Anticipate usage volume growth

  • Determine the performance influence of system parameter settings

  • Evaluate the influence of a global user distribution

  • Analyze the effects of custom coding

  • Devise archiving strategies

The predicament is that this information may not always be at hand, and you need strong communication between the business and application owners to locate it. In the following section, you will look at possible sizing strategies and methods for implementing new processes and applications — or perhaps for sizing even well before you have a test system. Later you'll learn about additional sizing methods for other phases of a solution's life cycle.

Different Scopes of Sizing for New Functionality

When implementing new applications or processes, you may need to order hardware — or at least secure sufficient financial resources for that hardware — before your business blueprint is complete, even if you are new to SAP software or are familiarizing yourself with a particular business application. Consider, for example, that your manager has ordered the latest business application, but the actual usage has not yet been defined. You still need to start your sizing project now, so how do you go about determining precisely what hardware resources you need?

Depending on your company size and situation, you may adopt one or a combination of three different sizing strategies.

Initial Sizing

Initial sizing is helpful for a first projection when you have very little starting knowledge. This sizing approach makes many assumptions about the usage and setup of business processes, thus allowing for very little alteration. This approach may work, however, for small businesses trying to determine their hardware budget.

Consider, for example, that you're implementing an E-Selling scenario within mySAP CRM, such as Internet Sales, and you're looking for an initial sizing estimate. Here you could use the Quick Sizer — SAP's online sizing tool (see sidebar) — to provide you with an initial sizing result for CPU, disk, and memory, based on the number of concurrent users in the Internet Sales scenario.

In the case of mySAP CRM, the Quick Sizer result is based on the regression measurements of a business case taken from an Internet Sales scenario with optimal settings, straightforward customizing, and scripted users. So if you deploy Internet Sales with a similar scenario, you can get a preliminary idea of the required hardware.

The advantage of the initial sizing exercise is that you need very little information to get workable sizing results. The disadvantage is that the scope is limited, in that sizing is based on numerous assumptions of business settings and throughput behavior.

An Introduction to Quick Sizer 2005

The Quick Sizer, SAP's online sizing tool, can assist you in translating the business requirements of your new SAP solution into hardware-independent sizing recommendations. The Quick Sizer is available for free on the SAP Service Marketplace for customers and partners.

To get a basic sizing recommendation from the Quick Sizer, follow these steps:

  1. Go to http://service.sap.com/quicksizing.

  2. Create a sizing project and fill in the online questionnaire with the relevant information, such as number of users, etc.

  3. Get an initial sizing result for CPU, disk, and memory (see Figure 1).

  4. If necessary, add additional guidelines; for example, to account for IDocs sent from server A to server B, you would add 10% load per object on the emitting system.

  5. Check for sample hardware configurations at www.sap.com/benchmark.

  6. Provide hardware vendors with your Quick Sizer project name and additional guidelines.

  7. Use the results you obtain to help select a balanced system that matches your company's business goals.

The Quick Sizer is designed to follow an 80/20 rule, meaning that it addresses those 20% of SAP transactions that usually account for 80% of the load in a productive system. The Quick Sizer is deliberately not designed to contain all sizing guidelines, so that it focuses on the most commonly used, bread-and-butter business scenarios.

For helpful documentation and a more detailed look at the Quick Sizer tool, visit http://service.sap.com/quicksizing --> Quick Sizer Tool --> Using the Quick Sizer.

Figure 1

Analyzing Quick Sizer's Results

Advanced Sizing

Advanced sizing is an approach, typically for larger companies, that considers throughput variations, quantifies business objects, and projects disk growth. An example of this can also be found in the Quick Sizer, where you can individually size the number of customer orders, service orders, activities, opportunities, calls, and emails to a customer interaction scenario of mySAP CRM. You can enter the number and size of the above business objects created in one year, and on top of that you can specify one or several peak processing periods to find out what your maximum CPU requirements are. By specifying the residence time, the Quick Sizer helps you to project disk growth; for example, the tool could display an overview chart of the 30 largest tables and their respective indexes, including archiving objects for tables and sizing objects.

The advantage of this approach is flexibility, especially in the number of possible variations to reflect different online usages and even background processing. The disadvantage is that you need to have the business object and volume information, which may be difficult to obtain. Although this approach may be more accurate than initial sizing, it still includes many assumptions, as well as an established standard business flow based on the regression measurements of an SAP business blueprint. Advanced sizing, however, may be sufficient for small and medium businesses, and may even satisfy some aspects of large corporations, depending on the deviations from the standard SAP software and the total data volume.

Expert Sizing

Though sizing tools may be helpful, all tools are limited in their ability to predict precisely the day-to-day changes and challenges that your business may face when running the solutions in production mode; expert sizing addresses this concern by using real input numbers to arrive at sizing results. Expert sizing focuses on your business application by analyzing the actual implementation and business volume flow. As a precondition, you need to have the software implemented, even if it is on a test system.

With expert sizing, you measure the performance KPIs of your own application analogous to what SAP does per default on its standard applications: You determine the bread-and-butter transactions, set up test cases, possibly automate them for later upgrades, measure the KPIs, and project growth based on your planned volume.

In addition, you may use some functions of the Quick Sizer tool, if applicable. For example, if your measurements showed that your sales order performance is twice as "expensive" as the order in the Quick Sizer, you could use the functions of the Quick Sizer for average and peak calculation, and then double the result. Of course, you could also create custom sizing questionnaires for your very own top 20 transactions and scenarios.

As for advantages and disadvantages, they are quite obvious: While expert sizing is the most exact of the approaches we've investigated here, it also demands the most monetary, resource, and time investments. SAP recommends examining very closely the extent to which this approach should be used. Expert sizing is absolutely recommended for large companies, complex business structures, and custom coding. In some very large enterprises, this approach is helpful, as it constitutes part of the work that must be done prior to volume testing to detect performance bottlenecks.

Sizing Strategies for Later Phases of the Solution Life Cycle

The above approaches are all geared at sizing new solutions and business applications. If SAP software is already up and running, you may take the following approaches throughout the different stages of a solution's life cycle:

Resizing

A resizing approach is appropriate when you are extending an existing application by volume and time periods only. The method is quite simple: monitor CPU utilization, table growth, and memory usage; relate it to a meaningful business entity, such as the number of concurrent users or the number of active projects; and add the load coming in through the additional users and projects.

Here, since your own productive data is apt to provide a meaningful basis for predicting hardware requirements, we do not recommend using the Quick Sizer tool. Instead, you can use the performance monitors of the SAP system to track CPU and memory utilization (OS monitor, ST06), database growth (database monitor, DB02), and frontend network load (statistical data records, ST03N). Based on these monitoring results, you can determine if your current hardware is sufficient or if you need to purchase additional hardware.

Delta Sizing

If you are adding new functions to an existing system — for example, you've decided to add supply chain management functionality to your existing ERP solution — a delta sizing approach would be your best bet. With delta sizing, you take note of current utilization and add the projected load of the new functions, which you can use the Quick Sizer to estimate. This effort combines actual software requirements with the initial, advanced, or expert approach.

Note!
In delta sizing, only use the Quick Sizer for sizing the new business functions (the delta itself). Remember that the algorithms and parameters of the tool are based on an SAP standard. Your current system workload, though, is based on your own parameter settings and customizing, making it the best basis for any sizing initiative.

Upgrade Sizing

When performing an upgrade, you must be aware of the different upgrades you're facing, including hardware, platform, or software release upgrades. The best approach is to analyze each upgrade by itself and add the resulting requirements, if needed.

This is a second case where we do not recommend using the Quick Sizer tool. Hardware and platform vendors provide their own upgrade information, and SAP performs regression testing of their standard business test cases (about 100 top transactions), summarizing the findings in notes that describe the influence of the upgrade on CPU, disk, memory, and frontend network throughput in a hardware-independent format. If you installed the new release on your own hardware — a test system, for example — you can quantify your sizing needs much better by benchmarking your key transactions in both the earlier release and the new one, and comparing your results.

Choose the Right Method for Your Company's Needs

Figure 2 is a summarized comparison grid of the different sizing methods, their relative complexity and accuracy, and their scope. From left to right across the figure you can see the different sizing tools and methods, which we'll discuss in more detail in the next section. Across the top of the graphic, you can see the target groups and different sizing goals:

  • Small and medium businesses, for example, may achieve fairly accurate sizing results using the Quick Sizer alone

  • Larger and more complex projects may use the standard tools, along with some additional hands-on exercises, to arrive at their sizing results

  • Large corporations with complex system infrastructures should verify their sizing assumptions with performance tests
Figure 2
The Scope of Sizing Tools and Methods

For all businesses, the sizing exercise is not finished after go-live; resizing, delta sizing, and upgrade sizing may still have to be applied.

A Range of Sizing Tools from SAP

Figure 2 also demonstrates that you can start your sizing project using one method or tool, but as your project evolves, you may need to redefine your approach and use different sizing tools in later phases of the solution life cycle. SAP provides a mixture of online tools and offline guidelines whose individual determinations can be combined to arrive at the most accurate, conclusive sizing results.

The Quick Sizer can assist you in translating the business requirements of your new SAP solution into hardware-independent sizing recommendations (see sidebar "Introducing Quick Sizer 2005"). The tool is available for free on the SAP Service Marketplace for customers and partners.

The Quick Sizer contains independently calculated sizing methods, user sizing, and throughput sizing. User sizing — which renders CPU, memory, and disk sizing estimates based solely on the number, type, and distribution of users — is helpful for small businesses and memory sizing. Throughput sizing, which determines CPU and disk sizing estimates based on business objects and transactions, is absolutely required for high-volume business.1

Quick Sizer addresses these essential sizing KPIs:

The CPU sizing results are calculated against a target CPU utilization of 65%. Ideally you would observe 65% CPU utilization if you ran the same processes used in the Quick Sizer and purchased hardware to meet the CPU sizing recommendations, which are measured according to the SAP Application Performance Standard (see sidebar).

SAP's disk recommendation considers the size of the DB tables in the SAP Data Dictionary, so that disk sizing is independent of the platform. It focuses on the length of time the data remains in the database until it is deleted or archived. Queuing tables, master data, and intermediate data, for example, are usually omitted, depending on the business process.

The memory recommendations are relatively hardware-independent.2 Memory sizing considers Unicode (if mandatory for the solution), along with garbage collection, user contexts, and so on. Note that SAP assumes one physical application server, and thus accounts for the memory needed for buffers and caches on that server, as well as on the database. If you eventually employ numerous application servers, simply add the requirements.

Please note that if you cannot find a particular application or partial solution in the Quick Sizer, there may be a number of reasons for this. For example, if you are using a new solution, SAP would prefer to do an initial one-on-one sizing to learn how customers use the new solution. Or, if the projected load of the solution you are looking for is negligible, the application may not be included in the Quick Sizer.

A Performance Yardstick: SAPS

As CPU measurements are highly CPU- and OS-dependent, a hardware- independent unit, SAP Application Performance Standard (SAPS), provides you with a performance yardstick. SAPS is one of the results determined by the measurements of SAP's de facto industry-standard benchmark, the SAP SD application benchmark. In the SAP world, each server has its own SAPS value, and every hardware vendor knows the SAPS of its servers. You can find some examples of published measurement results at www.sap.com/benchmark.

For example, if your Quick Sizer CPU result is 4000 SAPS, you can view a number of very different platforms, CPU types, and configurations that have achieved this result in an SD two-tier benchmark, and are therefore comparable and likely to fulfill your system requirements.

Beyond the Quick Sizer, other sizing tools provided by SAP include:

  • A simple sizing guideline, which SAP has termed T-shirt sizing, uses basic algorithms (with many assumptions) to provide recommendations for small, medium, large, and extra-large configurations (see Figure 3).

  • In some cases, SAP provides offline formulas to do some simple calculations, such as in the case of network sizing (see Figure 4).

  • Sometimes the solutions are so complex that a tool would be insufficient to provide a meaningful result. For example, in the banking industry, a questionnaire helps collect the needed information for sizing a commission system (see Figure 5). After completing the questionnaire, the bank then sends it to a sizing expert at SAP who provides sizing results and hardware recommendations.

For our sizing, we assume the following:

  • There are no configurable products
  • Group conditions are included
2.1 Sizing the IPC for the E-Selling B2B Scenario
In this case, we assume that customers enter the article numbers directly and only do one pricing step for the shopping basket.
Category Up until # line items per hour SAPS
Small 20,000 300
Medium 40,000 600
Large 80,000 1200
Extra Large 320,000 4800
Figure 3
An Example of "T-Shirt Sizing" Guidelines

The following formula is intended to give you a basic idea of what network load may be expected. Note, however, that we strongly recommend that you conduct measurements on the most important transactions yourselves.
C = X * N * D * 0.25  

The parameters are as follows:

  • C: Bandwidth in kbps that is needed for the UI
  • X: Amount of data per dialog step in kB
  • N: Number of active users (independent of the number of sessions)
  • D: Average number of dialog steps per minute per user 8
  • Numerical factor: ~0.25 = 8 (kb/kB) * 1.25 (protocol overhead) * 1/60 (min/s)

    * safety factor 1.59 (response time, peak load, different technologies)
Figure 4
Sample Offline Formula

Figure 5

Sample Sizing Questionnaire

Through a combination of these sizing tools and techniques, SAP can provide clear recommendations as you plan and conduct your sizing projects.

Conclusion

Sizing is an ongoing, cyclical process that brings together customers, hardware vendors, and SAP. Only in very few circumstances can you have a reliable sizing result after a couple of analyses, so rushing through a last-minute sizing project is definitely not a recommended course of action. Part of the success of the sizing exercises you undertake is your own understanding of where you are in an SAP project, the scope of the methods and tools you apply, the basic functions of the solution, the flow of the business transactions within and possibly across multiple servers, and the software components required. While sizing is based on measurements, it's also based on estimates and assumptions. Since real life is different from these assumptions, the accuracy, comprehensiveness, and detail of your sizing input is essential to determining the quality of the output.

The good news is that you have several different tools and methods available, depending on the phase of the implementation project. Some of them are concrete and to the point, while others consist of sets of guidelines to boil down any type of enterprise business application to key performance indicators, including CPU, disk, memory, and network throughput requirements. Alone or in combination, these sizing tools and methods enable you to work confidently with your hardware vendors to arrive at an optimized, right-sized hardware landscape.

For more information, please visit the SAP Developer Network (www.sdn.sap.com --> Weblogs --> Quick Sizer) and the SAP Service Marketplace at http://service.sap.com/sizing and http://service.sap.com/quicksizing.


1- For more information on user-based and throughput sizing, see the presentations "Sizing by Users" and "Sizing by Throughput," available for download at http://service.sap.com/sizing.

2 - There is currently some discussion surrounding 32-bit vs. 64-bit architectures, but after some time all customers will have moved to 64-bit.


Susanne Janssen joined SAP in 1997 after finishing her studies in applied linguistics and cognitive science at the Universities of Mainz and Edinburgh. She has been a member of the SAP Performance, Data Management, and Scalability team since 1998, where she manages sizing processes, projects, and customer contacts, as well as supports the rollout of the performance standard. She is also responsible for the cooperation of SAP and technology partners and hardware vendors in the area of sizing.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ