In the continuation of my previous article, White Paper SAP Sizing Solution Based on Users and Workloads – Part 1 | SAP Blogs
White Paper SAP Sizing Solution Based on Users and Workloads – Part 2 | SAP Blogs
This article describes SAPS calculation for the number of named users and based on SAP workloads.
SAP QuickSizer tool: To Obtain SAPS for the number of named users
Click the following website link
http://service.sap.com/quicksizing
Sample result for the SAPS value is shown in the figure
[A] SAPS value based on Workloads
After obtaining SAPS for given users from the SAP QuickSizer tool, additionally, the following lists must be taken into account for calculating SAPS value.
These are
- Custom Objects
- Interfaces
- Batch Loads
- Unicode
- Database size used
[B] Rule of Thumb for Custom Objects:
Nearly all SAP customers have a large number of custom objects. Objects can be programs, tables, function modules, etc.
Custom programs consume much more SAP extended memory and high CPU utilization takes place because of inefficient coding thus leading to expensive SQL statements and this result inefficient Explain Plan.
Hence SAPS value for custom objects is also to be considered.
Based on EWA reports from various customers, it is recommended that custom objects with reporting required SAPS to be increased by 30% as a user executes most of the custom objects in a Dialog work process. Thus, taking custom objects into account
New SAPS for Custom objects = 30% of SAPS obtained from the SAPQuickSizer tool
[C] Rule of Thumb for Interfaces
Additionally,, 15 % more for standard SAP BI interface with SAP ECC system is taken into account (since SAP Business Intelligence i.e. BI 7.0 extracts data from ERP 6.0, hence heavy processing takes place in ERP 6.0 system (see the transaction code sm50 with user “Aleremote” ) thus drastically lowering the performance. Hence required SAPS value is increased by 15%).
Furthermore, the Non-SAP interface with the ECC system is to be taken into account i.e. ERP system send/receive data from non-SAP using IDOC. Hence required SAPS value is increased by 5%. Thus, for SAP Bi and non-SAP interface with ECC system = 15+5 = 20%. Therefore
New SAPS value for Interface = 20% of SAPS obtained from SAP Quick Sizing tool.
[D] Rule of Thumb for Batch Loads
Experience showed that batch load depends on the number of application servers including the primary instance. The number of dialog instances required depends on the number of users executing batch loads.
For example, assume 1000 named users. one Primary instance and one Dialog Instance installed. In this scenario, batch loads for two servers will be extremely high where a large number of batch jobs processing takes place because batch jobs are distributed in only two servers only.
However, if there are three Dialog instance servers installed in addition to the Primary instance server, batch jobs are distributed in four servers. Hence load in each server can be medium to high for the same number of users.
If there are more than five Dialog instance servers installed in addition to the Primary instance server, batch jobs are distributed in six servers or more. Thus, load in each server can be low to medium.
Note that, experience shows that more batch jobs running in parallel in all application servers installed, consume most of the Extended Memory and Heap memory and also high IO utilization will take place on the database server. This will slow down overall Production system performance i.e. there will be highly intensive read / write operation on Disk/filesystems storage in the database server.
Thus it is advisable to schedule the jobs after office hours.
Also, It is advisable not to increase the number of background work processes above 3 during office hours i.e. should not be more than three background work processes in each application server including the primary instance server.
This will lower the usage of extended and heap memory, improve IO performance and enable end users to work in the SAP production system comfortably.
It is recommended that 25% extra be taken into account for up to 3000 named users
Thus new SAPS value for Batch load = 25% of SAPS obtained from the SAP QuickSizer tool
[E] Thumb rule for Unicode System loads
Unicode systems use between 1 and 5 bytes of space to store single characters. As a result, the resources of the system could be doubled.
Practically, the load on the CPU caused by the applications, increased by about 25-35%. The load on the RAM, again caused by application programs/transactions increased by about 50%.
It is advisable that 25% extra be taken so the required SAPS is increased by 25% for the database size up to 2.5TB and irrespective of the number of users.
Thus SAPS for Unicode system = 25% of SAPS obtained from the SAP Quicksizer tool.
[F] Final SAPS results for a Production system
Total SAPS value (F) = SAPS value obtained from SAP quick sizer tool (A) + SAPS value obtained from Custom Load (B) + SAPS value obtained from Interfaces (C) + SAPS value obtained from Batch load (D) + SAPS obtained from Unicode (E).
A sample example is shown in the figure below.
Accuracy has been estimated at 55% because we have taken estimated value for custom loads, interfaces, Unicode, and batch loads.
Also, other processes such as database size used, Monthly/Quarterly/yearly closing account, full offline/online backup, etc are not taken into account.
Conclusion:
Quicksizer estimates are based on assumptions. This white paper describes sizing exercises which include custom objects, interfaces, Batch loads, and Unicode to obtain SAPS in more accurate results.
Sizing is an iteration process i.e. ongoing exercise. This is strongly advisable to perform sizing every two to three years as the database size will grow
Reference:
https://www.sap.com/about/benchmark/sizing.html
http://service.sap.com/quicksizer – For Sizing exercises, the QuickSizer tool from SAP MarketPlace
Thanks for reading!
Follow for more such posts by clicking on FOLLOW => Prasad Rao
Please share your thoughts and feedback on this blog in a comment.
Prasad Rao
