## 5 Methodology, Experiments and Results
### Results
#### 5.2.1 AR Analysis  
AR represent one of the very important concepts of machine learning and allow us to learn about the data structure. They help in the analysis of a set of variables in order to find \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Architecture** & & _A1_ & & _A2_ & \\ \hline Processors & & 8 & & 12 & \\ RAM [GB] & & 20 & & 30 & \\ \hline Container structure & C1 & C5 & C10 & C1 & C5 & C10 \\ \hline \hline \end{tabular}  
A web server receives many kinds of requests based on prepared scenarios.  
\end{table} 
Table 2: Multi-container environment. Figure 2: Multi-container environment for _A1_. repeating relationships occurring in it. In this article, rules find relationships between sets of elements of every distinct request. This information can be used in the future as a basis for selecting system parameters. AR were generated for each of 54 cases (27 cases for \(A1\) and 27 cases for \(A2\)). The steps in generating results (Algorithm 1). ```
1:data table, support, number of bins for discretization
2:for every PARAMETER do
3:if variance of PARAMETER is equal to zero then
4: remove PARAMETER
5:else
6:continue
7:endif
8:for every REQUEST do
9:if REQUEST contains NaN then
10: remove REQUEST
11:else
12:discretization (\(K\)BitsDiscretizer from \(S\)cikit-learn library to discretize continuous features) of numerical parameters with quantile strategy
13:endif
14:endfor
15:for every PARAMETER do
16:one-hot encoding of PARAMETER
17:endfor
18:discretization of continuous values in data with quantile strategy
19:one-hot encoding data
20:generate association rules with Apriori method (\(mlx\)_trend_ library)
```  
**Algorithm 1** Pseudocode of the proposed AR  
Parameters as antecedents: _memory_usage_, _cpu_time_spent_user_, _cpu_time_spent_system_, _cpu_time_spent_idle_. Parameters as consequents: _num_sql_queries_, _cpu_time_spent_user_, _cpu_time_spent_system_, _cpu_time_spent_idle_. The steps after obtaining results from the AR algorithm were as follows:  
* Finding antecedents with the same consequents for all architectures (\(A1\_\_\)C1, \(A1\_\_\)C5, \(A1\_\_\)C10 and \(A2\_\_\)C1, \(A2\_\_\)C5, \(A2\_\)C10). * Searching pairs with the biggest support and confidence. * Joining duplicates. * Tabular summary division according to scenario (Table 3) or number of requests (Table 4). Possible rules for all data (we chose the first and second one):  
* _memory_usage_\(\Longrightarrow\)_num_sql_queries_
* _cpu_usage_current_\(\Longrightarrow\)_num_sql_queries_
* _cpu_time_spent_user_\(\Longrightarrow\)_cpu_time_spent_idle_
* _cpu_time_spent_user_\(\Longrightarrow\)_cpu_time_spent_system_  
AR can tell us a lot about data. Their task is to find dependencies in the data. They show the relationship between the features. The first rule describes the situation where there is a similar number of SQL queries. Repeatability was noticed for a specific number of containers and a specific architecture. The first summary of the AR analysis results includes _memory_usage_ (predecessor) and _num_sql_queries_ (successor), for the same value of _num_sql_queries_ (9-18). As one can see in Table 3 for architectures, e.g., \(A2\_\_\)C5 (5 containers), \(A2\_\)C10 (10 containers), memory consumption (_memory_usage_ predecessor) is similar regardless of scenario and the number of requests (slightly higher for architecture \(A1\)). For architectures with more containers, memory consumption successively increases from 15 to 20 (\(P1\)-\(P9\)), for 23-24 (P10-P18) to 25-27 (\(P19\)-\(P27\)) for \(A1\) and from 13 to 16 (\(P28\)-\(P36\)), for 16-18 (\(P37\)-\(P45\)) to 17-20 (\(P46\)-\(P54\)) for \(A2\). For the same number of requests (e.g., \(P10\), \(P13\), \(P16\)), the memory consumption (Table 4) is even closer (1-2%) for different scenarios. AR proved to be very useful in this case. The scenario and the number of requests have been shown to have no significant impact on memory usage.