In this and subsequent blog posts we will explore several topics related to the sizing of the SAP BPC 10.0 NW application. In this first post (Part 0: Preliminary Information) we present a brief recap of the standard sizing guide and methodology, while subsequent posts will dive into an array of extended subjects. Topics anticipated for inclusion: expert sizing of CPU / SAPS requirements, a probabilistic approach to buffering these SAPS calculations, special considerations for a variety of customer scenarios, and empirical tests of simple hardware configurations.
Part 0: Preliminary Information
The primary source for sizing of the SAP BPC 10.0 NW application is the sizing guide available on the SAP service marketplace (see below).
http://service.sap.com/sizing > Sizing Guidelines > Analytics > EPM: SAP Business Planning and Consolidation NW & HANA 10.0
It is important to note: the sizing requirements contained within the BPC sizing guide are for the BPC application only, not for the entire BPC system. SAP BPC sizing must be done in two steps: you need to size the BW foundation first and then add the BPC requirements on top of this foundation. (Please refer to http://scn.sap.com/docs/DOC-60565 for details.)
For example, you will find in the sizing guide that the sizing for the simplest implementation class (in terms of complexity / number of concurrent users) of BPC 10.0 NW on HANA is: 900 CPU SAPS and 8 GB memory for the application server, and 700 CPU SAPS, 42 GB memory and 73 GB disk for the HANA database. But if you use these numbers as sizing for the entire BPC system, the system will most likely be undersized. The application server sizing amounts to just 1 CPU core, which is not enough to run a BPC 10.0 NW system. And even without populating the database with any business data, a newly-installed BW system will already use more than 42GB of memory on HANA.
Within the SAP BPC 10.0 NW sizing guide you will find two methods for sizing the planning functionality.
- The simplest method is to assess the customer’s environment by level of complexity and user load, matching it to one of nine predetermined classes for which sizing recommendations already exist. Specifically you will find recommendations for the application server SAPS and memory requirements, as well as database server SAPS, memory, and disk requirements.
- The more complicated method is to calculate the application server and database server requirements from a customized user profile distribution, where the customer specifies how many users are expected to be simultaneously running each of 10 predetermined user profile tasks
In method 1 above, the customer’s environment is first classified as belonging to one of three complexity classes – Categories 1, 2 or 3 – depending on whether the implementation is medium-sized, large, or a large enterprise deployment. The guide itself contains further details, where each such category is defined in terms of statistics such as the number of dimensions, the maximum number of dimension members, the number of transactional records in the environment, the script logic complexity, etc.
Next, the expected number of concurrent users is specified: 50, 150 or 300 users. Based on both the complexity category and the concurrent user count, the included tables provide the estimated application server and database requirements for each of the nine possible configurations. See below for several sample tables.
The above tables assume that the customer is using a combination of both the EPM Add-In frontend and the web frontend. A separate set of tables exists for customers using only the EPM Add-In frontend.
So for example for a Category 3 implementation of BPC 10.0 NW on HANA with 150 concurrent users using both the EPM Add-In and web frontends, the above tables recommend: 34,000 CPU SAPS and 30 GB of memory for the application server, and 31,000 CPU SAPS, 52 GB of memory and 108 GB of disks for the HANA database. Again, this is in addition to the sizing requirements of the BW foundation on which the BPC application sits.
Sizing via method 2 above is a refinement of method 1 in that the customer is given further control over the number of concurrent users and the user profile distribution itself, i.e. how many of the expected concurrent users belong to each of the different user profiles.
There are a total of 10 BPC user profiles presented in the sizing guide, and provided for each is a definition of the actions that such a user performs and the “think time” (or wait time) between each repeated cycle of such actions. See below for a sample.
The BPC sizing guide then provides the system requirements of a single user executing the tasks of each such user profile, where again the requirements are separated into one of three categories depending on the complexity of the implementation. See below for one such table describing the single-user application server requirements for each of the user profiles.
The total sizing requirements for the application server are then calculated by multiplying the single-user requirements above by the number of concurrent users belonging to the corresponding user profile, and then summing across all such relevant user profiles. There are similar tables for sizing both traditional and HANA database requirements as well. See the sizing guide for the full details and for example calculations.
Note that sizing by method 1 is simply a special case of sizing by method 2, where the user profile distribution across 50, 150 or 300 users is already pre-determined (and hence the sizing calculations pre-performed).
Please see the sizing guide for further information about each of these sizing techniques, as well for additional background information and for some similar details on the sizing of consolidation functionality.
While the preceding sizing methodology is convenient, it is not without its limitations. In the next post we will explore some of these limitations, and we will use this as a jumping-off point for further techniques and topics related to the sizing of the BPC 10.0 NW application.