## 5 Methodology, Experiments and Results
### Results
#### 5.2.2 RT Analysis  
Once an RT is built it can be used to predict the requests class of the customer or the behavior scenario. The steps in generating results (Algorithm 2). The steps after obtaining the results from the RT algorithm were as follows:  
Return to the categorical values. Ordering according to the number of processors, the number of containers, the scenario and the number of requests. Division into architecture \(A1\_\_\)C1, \(A1\_\_\)C5, \(A1\_\_\)C10 and \(A2\_\_\)C1, \(A2\_\_\)C5, \(A2\_\_\)C10. Preparation of charts (Figure 2(a)-d). ```
1:data table
2:for every REQUEST do
3:if REQUEST contains NaN then
4: remove REQUEST
5:else
6: adding the parameters (number_of_cpu, RAM, number_of_containers, number_of_queries_global, scenario) of experiments to dataset
7:endif
8:endfor
9:original encoding (the sklearn.preprocessing package) of categorical parameters (_scenario, container_id_)
10:generating tree with parameter \(cpu\_time\_spent\_user\) as target (_Scikit - learn_ decision tree classifier)
11:tree structure
```  
**Algorithm 2** Pseudocode of the proposed RT  
The number of containers for \(A2\) does not affect the value of \(cpu\_time\_spent\_user\) (Figure 2(a)). More processors ensure consistent processing regardless of the number of containers. An identical trend can be observed in the case of the implementation of scenarios on different platforms (Figure 2(b)). The medians for the \(S1\) and \(S3\) scenarios are similar (Figure 2(b)), and for the \(S2\) scenario it is always much higher. This makes it possible to distinguish between test cases (scenarios). For the \(S2\) scenario, the median for different number of containers (Figure 2(c)) remains almost constant, unlike the other two cases where there are much larger discrepancies. The same is true for the chart of different numbers of requests (Figure 2(d)), although perhaps not quite as clearly as it is for the previous chart (Figure 2(c)). As the presented analysis shows, the results for the \(S2\) scenario differ significantly from the other test cases. As the description (Table 1) shows, this scenario contains a decidedly different query sequence. The analysis of the output data only confirms this state, \begin{table}
\begin{tabular}{l c c c c c c c c c c} \hline \hline
**Architecture** & \(A1\_\_\)**C1** & \multicolumn{2}{c}{\(A1\_\_\)**C5**} & \multicolumn{2}{c}{\(A1\_\_\)**C10**} & \multicolumn{2}{c}{\(A2\_\_\)**C1**} & \multicolumn{2}{c}{\(A2\_\_\)**C5**} & \multicolumn{2}{c}{\(A2\_\_\)**C10**} \\ \hline
**Range of Values** & **Min.** & **Max.** & **Min.** & **Max.** & **Min.** & **Max.** & **Min.** & **Max.** & **Min.** & **Max.** & **Min.** & **Max.** \\ \hline \(S1_{100,000}\) & & & & & 90.4 & 97.4 & & & & & 95.3 & 98.1 \\ \(S1_{400,000}\) & & & 78.7 & 81.4 & 93.3 & 95.7 & 16.7 & 19.8 & & & & 95.3 & 98.1 \\ \(S1_{700,000}\) & 20 & 22.2 & & & & & & & & 60 & 62.6 & & \\ \hline \(S2_{100,000}\) & & & & & & 89.5 & 93.3 & & & & & 93.3 & 95.7 \\ \(S2_{400,000}\) & & & & & 90.7 & 95 & 16.7 & 20 & 62.9 & 71.6 & & & \\ \(S2_{700,000}\) & 17.9 & 19.6 & 76.9 & 79.1 & 94.7 & 98 & & & & & & \\ \hline \(S3_{100,000}\) & & & & & & 88.5 & 93.5 & & & & & \\ \(S3_{400,000}\) & 29.4 & 31.7 & 76.9 & 79.5 & 89 & 96.7 & 16.7 & 20 & 61.1 & 67.7 & & \\ \(S3_{700,000}\) & & & & & & & & & 61.5 & 64.3 & & \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Summary of the \(cpu\_usage\_current\) [%] results by scenarios and number of requests. which allows us to conclude that it can be useful for recognizing the behavior of the client (scenario) of the system. The 2D analysis presented is complemented by the results of the 3D analysis (Figure 4a,b), which only confirms the previous conclusions. It has been shown that the scenario has a significant impact on CPU usage. Results of _cpu_time_s_pent_user in scenario \(S\)2 (Figure 4a) for different platforms (\(A1\) and \(A2\)) and different number of client requests (100,000; 400,000; 700,000) are stable for \(A1\) and \(A2\), respectively.