Introduction
Prerequisite to the concurrent users load CPU sizing is applying the HANA analytical application procedure for response time prediction as described in
https://blogs.sap.com/2014/11/28/practical-approach-for-response-time-prediction-of-hana-analytical-... . The outcome of this procedure is:
- The query specific sequential (S[s]) and parallel (P[s]) part are determined in seconds.
- The minimal possible response time which can be achieved, i.e., the response time obviously cannot be shorter than the calculated sequential processing time.
- Trade-off analysis of processing time vs hardware cost is done and the optimal target response time (TargetRT[s]) is identified.
- Finally, the number of sufficient Cores (N) to achieve the TargetRT[s] are calculated.
Methodology for Concurrent Users Sizing for HANA Analytical Applications
The goal of this sizing is to determine how many Cores (vCPUs) are required for the processing target number of parallel requests (
TargetPR) with the target response time (
TargetRT[s]).
Note!
- The number of parallel requests (TargetPR) is always an integer value, lower than the number of concurrent users. Typically, one user sends a request and then makes a pause (so called “think time”) to review the response data in the application UI. Usually, the parallel requests are in range of 5-10% of the number of concurrent users.
- To fulfill the TargetRT[s] requirement for just one request (parallel requests are still not discussed), N cores (vCPUs) must be available.
Determine "UsageRatio"
(F1) UsageRatio (%) = (TargetRT[s] – S[s]) / TargetRT[s]
Theoretically, the Target Response Time (
TargetRT[s]) is longer than the Sequential Part (
S[s]) and both are non-negative numbers. For this reason, always UsageRatio < 100%.
UsageRatio will be explained with examples:
If UsageRatio=0.77 (77%)., then N cores have capacity to handle 1 request at a time, but not enough capacity to handle 2 parallel requests, because 2*77% = 154% > 100%.
If UsageRatio=0.37 (37%) N cores have enough capacity to handle 2 parallel requests, because 2*37%=74% < 100% but are not enough to handle 3 parallel requests, because 3*37%=111% > 100%.
Determine "RequiredCores"
(F2) RequiredCores = N * roundup_to_Integer (TargetPR * UsageRatio)
Example:
- The customer set requirement for TargetRT[s].
- The number of cores, required to achieve the TargetRT[s] for single request is, for example, N = 16.
- UsageRatio, for example, 0.37 was calculated using formula F1.
The table below demonstrates the number of Required Cores (vCPUs) for running
TargetPR with a guarantee that the response time of the individual requests will be in the range of the defined by the customer
TargetRT[s].
N
(TargetRT[s] is defined by the customer) |
UsageRatio
(TargetRT[s] is defined by the customer) |
TargetPR
(Defined by the customer) |
Nr. of Required Cores (vCPUs)
(Sizing result) |
16 |
0.37 |
1 |
16 |
16 |
0.37 |
2 |
16 |
16 |
0.37 |
3 |
32 |
16 |
0.37 |
4 |
32 |
16 |
0.37 |
5 |
32 |
16 |
0.37 |
6 |
48 |
16 |
0.37 |
7 |
48 |
16 |
0.37 |
8 |
48 |
16 |
0.37 |
9 |
64 |
16 |
0.37 |
10 |
64 |
It is clear that for any target throughput the number of required cores is multipliable of N.
The result should be interpreted like this:
32 cores (vCPUs) are sufficient to handle up to 5 parallel requests at ~93% average CPU usage and are not sufficient to handle 6 parallel requests.
48 cores (vCPUs) can handle 6 parallel requests at ~74% average CPU usage; 7 parallel requests at ~87% average CPU usage and 8 parallel requests at ~99% average CPU usage. 48 cores are not sufficient to handle 10 parallel requests with the TargetRT[s].
and so on
Traditionally, following the general CPU sizing principles, the customers with bigger hardware budget, could apply a safety buffer, e.g., 10-35% on top, but it is not a must.
