Quick Sizer for Initial Sizing
As mentioned before, initial sizing, when you have only a vague idea of the expected workload is dominated by a user sizing. Sizing for your concurrent active users is pretty straight-forward in the Quick Sizer. It only takes into considerationusers that are logged on and consume system resources, for example in the Enterprise Portal or in mySAP CRM. In some solutions the Quick Sizer requires you to specify in which application the users work predominantly, in mySAP CRM, for example, it distinguishes between Opportunity Management, Activity Management, sales transactions or service transactions. In some user sizings you are requested to specify an activity profile, for example: how many users have a low, medium or high activity? The activity patterns merely expresse the number of screen changes per user per hour. A highly active user, for example, corresponds to a power user with a think time of 10 seconds between screen changes.
When youve entered the user information and choose calculate result, youll get the following information for each SAP solutionThe required
- CPU power in SAPS (hardware-independent, see above)
- Disk space in MB
- Memory in MB (in units of 256 MB)
For your convenience, there are categories for the disk and CPU result that indicate whether you are in a small or medium sized environment. As explained above, the initial sizing is only a very rough ballpark estimate which is why I would not recommend relying only on a user-based sizing if the result is higher than 5000 SAPS. User sizing per se is very inaccurate in the sense that it does not account for background processes, interfaces, and so on, and therefore the Quick Sizer provides high sizing results as compared to throughput sizing. So if you happen to do both user sizing and throughput sizing and find that the results deviate significantly, this can be either because you have specified a user activity that is too high or because the throughput sizing is more accurate.
The Quick Sizer does not offer user sizing for all applications. The Exchange Infrastructure (XI), for example, has no user sizing. As a pass-through engine, it has no dialog load. For this, we provide an initial throughput sizing for SAP XI.
Quick Sizer for Advanced Sizing
When you are a little more familiar with how SAP software represents your business applications, youre ready for advanced sizing based on throughput numbers. This sizing is usually more accurate for several reasons. The Quick Sizer contains some 120 sizing elements for throughput sizing that reflect the most common and potentially most load-consuming transactions and business applications for mySAP.com. The information the Quick Sizer wants to know follows a simple pattern: Number of objects (projects, printed documents, sales orders or travel receipts) per year, number of sub objects (networks, activities or line items) and how many months these data will remain in the database until they are archived. If you enter this information and choose calculate result, the Quick Sizer renders basic CPU and disk requirements (remember that memory is dominated by users). This sizing method is called average sizing from which you can build on towards a peak sizing.
The peak sizing method helps you to identify CPU peaks during the busiest day of the year (for example right before Christmas or year-end closing). You enter the number of objects and sub objects and specify the time period when these objects are being processed, for example: The payroll of 200,000 employees from 2 am to 4 am. If this run coincides with the nightly background run for the materials requirements planning, the Quick Sizer shows the peak CPU requirement. When we say peak sizing, we mean the peak over all individual sizing results. If the average sizing for a sizing element renders 1000 SAPS, and the peak sizing 1200 SAPS, the overall result of the sizing is 1200 SAPS. If the peak sizing should render a value below the average sizing (if specified by you), the Quick Sizer issues a message.
You can then go on redefining your sizing:
- For example, you can enter how often an object is changed per year or per peak phase. This influences the CPU sizing.
- You may also want to change the average workday. Per default, the Quick Sizer assumes that an average workday ranges from 9am to 6pm, which you can easily change, thus influencing the CPU result.
- The Quick Sizer also assumes 220 work days per year as a default. If you adapt this value to your needs, this also influences the CPU result for the average sizing. By the way, the number of workdays also influences the disk sizing for the users.
- You can extend the average sizing by allowing for multiple averages. For example: in a customer system, orders are created in mySAP CRM, by handhelds and by Interaction Center users. The orders are transferred to the ERP system for full order processing. By adding lines, you can distinguish between the orders that were originally passed on from the handheld scenario and the Interaction Center. To make this information transparent you can add a short text to each line. The Quick Sizer will add the averages and calculate the result for you.
- One function that, strictly speaking, is not relevant for the sizing calculation is the archiving flag. If you enter this, the Quick Sizer checks whether an archiving object for this sizing element exists.
Below find an example for a simple sizing of travel receipts. The number of objects field contains the number of travels, and the Line items field refers to the number of receipts.
Figure 1: Example for simple average sizing.
If you use all these functions, you can get a pretty accurate representation of the hardware required to run the business. However, this sizing will always be based on standard processes that SAP has designed and measured.
Quick Sizer for Expert Sizing
Expert sizing makes the utmost use of the standard functions of the Quick Sizer. Expert sizing is for customers whose business requirements encompass the rule of 80/20 (80% of the load is created by 20% of the transactions), first-and-foremost because of custom modifications, system to system data exchange, customization, and so on.
One standard function of the Quick Sizer that can be exploited for expert sizing is the possibility to set multiple averages against multiple peaks. The Quick Sizer always checks which sizing method renders the higher CPU value, average or peak. Using a function called ID for identification, you can specify which averages are calculated against which peaks. This is very helpful for complex scenarios, for example in the retail business or in the example above, where orders come in from very different sources. The figure below shows you an example. CRM-SLS is the CRM sizing element sales orders, A specifies average sizing, Y stands for objects per year.
Figure 2: Example for multiple averages.
If you do not enter anything in the ID column, all averages are added and calculated against all peaks, which may blur the result.
Also, you can use rules of thumb mapped to the Quick Sizer to account for special processes. For example, there is a rule that says to account for additional load caused by RFC processing, add 10% load on the sales orders that are transferred to another system. In this case, you would add an additional line for peak, enter 10% of the number of orders and add in the short text field additional RFC load.
Figure 3: Example for multiple averages against mutiple peaks and rule of thumb.
In principle however, expert sizing can only take place if the customer already has a test system up and running. Then we recommend using standard SAP system monitors to obtain sizing relevant information such as CPU time, table size and memory consumed per business process. If you have this information you can relate it to the Quick Sizer. For example, you have written your own sales order application and your measurements show that this is 1.5 times as expensive as the Quick Sizer sales order. Then you can simply exploit the functions of the Quick Sizer for your own software by applying a factor of 1.5.
Quick Sizer and GoingLive
SAP Support offers the GoingLive Check (GLC), and one of the features of GoingLive (GL) is the plausibility check of the sizing where the Quick Sizer entries and sizing results are checked against the performance capabilities of the hardware the customer has purchased.
This can be done on the basis of the sizing data. In some cases, GLC offers additional checks if certain business processes are not (yet) included in the Quick Sizer. When you are ready, you can simply set the status of your sizing project in the Quick Sizer to GoingLive. Then the ownership of the sizing projects changes to GoingLive, to SAP Support, that is. You yourself are not able to make modifications to this project until SAP Support has changed the project status to in process after GL. That way, SAP and customer can work together on the hardware plausibility check relying on the same data. If you set the project to final, no one can change the project anymore.
Interpreting Quick Sizer Results
For reasons of better analysis, the Quick Sizer allows you to analyze sizing results at very different levels of detail. Here are the most important ones.
Result at solution level
By default, the Quick Sizer displays the sizing result by sizing method (user and throughput) and by SAP solution, for example mySAP ERP or SAP Netweaver. For each solution the Quick Sizer displays the required:
- CPU power in SAPS (hardware-independent, see above)
- Disk space in MB
- Memory in MB (in units of 256 MB)
For easier analysis, there are also categories provided. If you only have a user-based sizing and if this result exceeds category 7, you should either perform a throughput sizing or contact your hardware vendor or SAP. If you did both sizing methods and the category exceeds 15, you should also contact the hardware vendor or SAP for help. For your convenience, you can display a chart of the CPU load over the day.
Result at software component level
To plan your system landscape it is helpful to know the hardware requirements for each software component, for example Enterprise Core Component (ECC) or Portal Server. On this result level, the results are also split to reflect load on the application server and on the database server, for example.
Display all inputs and all results
This function is predominantly useful for documenting the sizing project as it contains all the data you entered and all the results of the Quick Sizers. With the print function you can download this information to save on your PC. This function is also helpful if you want to analyze the sizing data in more detail. More often that you think you can detect erroneous entries by simply doing a plausibility check on the highest CPU or disk contributors. This result level also provides detailed information on the top disk contributors, the table names, the projected growth, available archiving objects, and so on.
For more information, see Blog on interpreting Quick Sizer results.