## 4 Results
### Experimentally Obtaining the Upper Limits for Horizontal Autoscalers
#### 4.2.3 Finding the Optimal Setting of \(H_{max}\) Parameter for HPAs  
The last step in the proposed method allows the optimal values of \(H_{max\_d}\) to be established subject to the given constraints based on the median of times of request execution and %errors.  
To find the optimal (or the Pareto-optimal) values of \(H_{max\_d}\) (\(d=1\ldots D\)), we must consider changing and setting all \(D\) values for each experiment, which allows us to evaluate the assumed quality indicator. If we assume \(J\) different values for each \(H_{max\_d}\), it will result in \(J^{D}\) experiments.  
Instead, we propose to only change the value of \(H_{max\_selected}\). \(H_{max\_selected}\) is the value \(H_{max\_d}\) for the deployment \(d\_selected\) that has the highest value of required pods, i.e., the deployment with the highest \(p_{d}\) in Table 5. The rest of \(H_{max\_d}\) is calculated using the \(H_{max\_selected}\). This significantly decreases the number of required experiments.  
Let us denote the following:  
\(J\)--the number of experiments;  
\(dH_{max}\)--the increase value (delta) of \(H_{max\_selected}\) for the sequence of experiments;  
\(H_{max\_selected}(j)\)--the value of \(H_{max\_selected}\) in the \(j\)-th experiment, where \(j=1\ldots J\):  
\[H_{max\_selected}(j)=H_{max\_selected}(j-1)+dH_{max}. \tag{9}\]  
The values \(H_{max\_d}\) (in the \(j\)-th experiment) for other deployments are calculated proportionally to the coefficient from Table 5 (with respect to \(H_{max\_selected}\) in the same \(j\)-th experiment):  
\[H_{max\_d}(j)=\text{ceil}(p_{d}H_{max\_selected}(j)). \tag{10}\]  
In the considered example, we started the experiments from the value \(H_{max\_selected}(1)=13\). In addition, \(J=9\) experiments were executed using the load profile described in Figure 5.  
The values  
The last column, named SUM, shows the total number of pods involved in handling the load in the \(j\)-th experiment. The number of pods had a direct impact on number of nodes provisioned by the Kubernetes cluster.  
The final results according to the criteria of the evaluation are presented in Table 8.  
The given efficiency indicator is based on the following:  
Me--the median of the execution times of the critical request;  
%error--the relative error (the number of failed requests compared to the total number of requests).  
The given cost indicator is based on the number of compute components:  
NoN--the mean number of nodes of the Kubernetes cluster used by the considered system.  
Generally, the best configuration could be selected as the optimal \(H_{min\_d}\) for a Pareto-optimal indicator based on Me, %error, and NoN. However, there are often known restrictions for some high-order quantile or the median of the execution times and %error. In the considered system, the client also gave the following conditions: Me < 2 ms and %error < 5%. Thus, we were only able to find acceptable configurations for \(j=5,6,7\). They are colored gray in Table 8.  
According to the obvious requirement of the lowest cost, we had to choose \(j=5\) from 5, 6, and 7, because of the lowest NoN value, i.e., 25.15. Therefore, the cost-optimal setting of the value \(H_{max\_d}\) for HPAs handling critical pods has the index \(j=5\).  
By analyzing the results of the specific experiments in Table 8, we managed to find a satisfactory solution that allowed us to save computational resources. If we compare the results for the acceptable solution--the most economical (NoN = 25.15 for \(j=5\))--and the fastest (Me = 1.33 s and NoN = 29.03 for \(j=7\)), we obtain a savings coefficient (29.03 - 25.15)/25.15 \(\times\) 100% \(\approx\) 15%.  
The culmination of the research results is the resultant optimal vector of values of \(H_{max\_d}\), which is highlighted in gray in Table 6.