End-To-End Sizing Calculation – Gateway Customer Scenario Example

The following example is provided to help you and Gateway customer to understand the delta sizing calculations for the SAP backend systems using flows called through SAP NetWeaver Gateway.

It illustrates initial sizing for backend components like standard SAP services or customer own code that is called remotely via SAP NetWeaver Gateway.

In addition, the example provides some recommendations on how to deal with, or avoid overloading of the backend systems.

More information about Gateway sizing can be found in the Gateway sizing guide document  located in http://service.sap.com/sizing → Sizing Guidelines → Solutions & Platform – New Structure → (1) SAP NetWeaver or (2) Mobile → SAP NetWeaver Gateway 2.0 SP05.

Data preparation for sizing calculations

1. Customer A identified the peak time period of one hour for their entire business flows. During this peak hour, the end users that consumed Gateway services triggered the most number of calls. For example, it can be Monday morning between 9:00 and 10:00 AM.
2. Customer A identified the most commonly used flows, out of all possible flows that consume Gateway. Usually, 20% of the flows are called in 80% of the   cases. Customer A also identified several flows out of the most commonly used flows in the existing CRM system, and some flows in the existing ERP system through Gateway. The ERP and CRM systems are already in use by non-Gateway scenarios, and customer A has collected information about the current CPU and memory utilization during a working day and required peak hour for application and database (DB) layers. This information is essential in order to find whether current ERP and CRM systems can handle the additional load initiated by Gateway.
3. Customer A extrapolated the maximum number of calls that will be called by every end user per each of the flows found in step 2 above. The number of calls extrapolation can be also done according to averages, but for more precise sizing, it is better to take the maximum. For example, the following information was identified:

              Maximum operations per peak hour table:

  In this example, total number of operations per end user per peak hour equals to 27. There are 7 operations in the CRM system and 20 operations in     the ERP system.

  For example, current CRM and ERP systems utilization (before Gateway) during the peak hour:

  SAP systems utilization during peak hour table:

The assumption is that the peak hour of the backend systems is not shifted by Gateway usage. Another assumption is that peaks for backend and Gateway systems are at the same peak hour.

   4.  Customer A must find the number of the end users that will trigger the calls toward Gateway during peak hour. (For example 10,000 users)

   5.  Customer A asked their hardware partner to provide the SAPS of ERP and CRM systems. If the customer’s hardware partner does not inform him about the SAPS of his systems, he can get similar systems at: http://www.sap.com/solutions/benchmark/sd2tier.epx. For example, the following SAPS numbers and memory were provided to a customer by the hardware partner.

  SAP systems SAPS & Memory table:

For more information about SAPS go to: http://www.sap.com/campaigns/benchmark/measuring.epx

Prerequisites for sizing calculations

     To start the sizing calculations, make sure that the following requirements are met:

1. Single user test requirements.
   Customer has to verify that every flow specified by him for sizing calculations meet his performance Key Performance Indicators (KPIs). Sometimes the customer has to implement Gateway interfaces, and has to verify that his implementation (especially in backend systems) meet his KPIs.
   The verification can be done by using STAD transaction by monitoring response time, CPU and memory consumption for every flow on your Gateway and backend systems.
2. The flow has scalable behavior.
   The customer has to verify at least data scalability dimension. Example for non linear behavior: the CPU consumption for retrieving 10 objects is 100 ms, but retrieving 100 objects it is 2 seconds. The expected CPU consumption for 100 objects retrieval is under 1 second.
3. The customer can verify also user scalability dimension by having parallel users as incremental factor and monitoring system resources.

Sizing calculations

Once Customer A completed the data preparation and prerequisites steps, customer A started with sizing calculation process in order to find SAPS values of his Gateway and backend systems.

First step:

Initially, customer A found CPU consumption of the Application and DB layers for Gateway and backend systems of every flow participated in the sizing guide by using STAD transaction. For example, the following are the CPU and DB consumption numbers for the single user flows:

Single operation consumption table:

Second step:

Now, customer A has to identify the required consumption on application and DB layers for all operations during peak hour per each flow and for all users.

In order to do so, every value in the table “Single operation consumption” that was found in step 1, will be multiplied with “Maximum operations per peak hour” table (see the section, Data preparation for sizing calculations) according to the flow description.

In addition, each value will be multiplied with the end users number (see the section, Data preparation for sizing calculations) which will trigger the calls toward Gateway during peak hour (10,000 users).

For example, Gateway total required consumption on application layer for “Query contacts” flow will be calculated as following:

The final calculation: 40*3*10,000 = 1,200,000 (ms). We can convert this number into seconds by dividing it by 1,000. And therefore 1,200,000/1,000 = 1,200 seconds.

Total consumption table:

Third step:

Since the operations will be executed during one hour, customer A calculated the number of single computing units (SCUs), it is needed to complete the required processes for Gateway and backend systems of application and DB layers per each flow. Customer A divided every value in table “Total consumption” by 3,600 per hour (1 hour = 60 minutes*60 seconds).

Number of SCUs required completing the required processes table:

Forth step:

Customer A identified the required SAPS values of Application and DB layers for Gateway and backend systems.

In order to complete the calculations, customer A identified the “Single computing Unit” SAPS value of the Gateway, ERP and CRM systems in which the measurements done.

For more information about “Single computing Unit” please read SAP Note number 1501701, or contact your hardware partner.

For example, customer A identified that “Single computing Unit” SAPS value of the Gateway, ERP and CRM systems equals to 1,000 SAPS.

In addition, customer A took into account that target CPU utilization on all layers for all machines should not exceed 65%.

In order to get the required SAPS value for application and DB layers on GW, EPR and CRM machines, customer A multiplied  “Single computing Unit” (1,000 SAPS) by every value in “Number of SCUs required to complete the required processes” table found in step 3 and divided each value by factor 0.65.

   Final SAPS values table:

The Total SAPS numbers represent the required SAPS for application or DB layers on Gateway, ERP and CRM machines for processing Gateway flows.

Customer A also identified the memory consumption required for Gateway flows for application and DB layers on gateway, ERP and CRM systems as following:

Gateway application & DB layers: memory consumption formula is 1,000 SAPS = 1.5 GB memory.

ERP & CRM application layer (only valid for Gateway scenarios): memory consumption formula is 1,000 SAPS = 1.5 GB memory. 

ERP & CRM DB layer (only valid for Gateway scenarios): memory consumption formula is 1,000 SAPS = 3 GB memory.

Fifth step:

Customer A identified the hardware required for Gateway system, and whether their ERP and CRM systems with current hardware can serve Gateway flows in addition to the current systems utilization.

Customer A contacted their hardware partner and requested for a Gateway server hardware according to the SAPS found in forth step.

As already mentioned in the section, Data preparation for sizing calculations, the conversion of SAPS to potential hardware is done by SAP technology partners.

In addition, customer A identified the percentage of ERP and CRM SAPS as found in forth step, out of the total amount of SAPS specified in the section, Data preparation for sizing calculations.

Percentage of required SAPS out of total SAPS table

Customer A identified the percentage of ERP and CRM memory consumption found in forth step out of total memory consumption specified in “Data preparation for sizing calculations” step 5.

The customer verified that his ERP and CRM systems can handle additional load which will be triggered by Gateway flows: Total load (Current & Gateway) table.

Customer A identified the ERP and CRM systems can handle additional load caused by Gateway flows since all the numbers are below 100%.

In case you identify that one of the total load values in percentage is over 100% you can consider the following:

1. Change the value target utilization to be more than 65%. Highly recommended for big systems and DB systems.
2. Consult your hardware partner regarding additional hardware resources. Add more Hardware to support additional load caused by SAP NetWeaver Gateway flows.
3. In case it is not possible to add more hardware for your existing SAP systems (especially DB layer), consider implementing the throttling BADI provided within SAP NetWeaver Gateway 2.0 SP5 version.

Customer A successfully implemented SAP NetWeaver Gateway solution and they are live with a production system.