# ReSQoV: A Scalable Resource Allocation Model for QoS-Satisfied Cloud Services
## 5 Experiment Results
### Scenarios Experiment Results  
This section first compares ReSQoV with the policy-based, time-sharing scheduling by vertical scalability defined by the varying number of users in the CloudSim Plus simulator [17]. It also measures the effect of QoS parameters on efficiency metrics. Finally, an analysis of our algorithm's robustness is presented. All the findings reflect the average of \begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Min** & **1Q** & **Median** & **3Q** & **Max** \\ \hline \(-5.8866\) & \(-1.1396\) & 0.1346 & 2.0116 & 4.3765 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Residual Values for the USL Model. Figure 5: USL Model for Concurrency and Response Time. the five experiment runs that were collected. One workload parameter is randomized in each experiment on varying processing elements (PE, CPU cores), where other resources RAM, Bandwidth, and memory, are given constant values. Four metrics are considered for each scenario to assess the efficiency of ReSQoV for QoS parameters (response time, throughput, number of PE used). The response time is calculated based on a Virtual Machine's length of workload (MI) and the Millions of Instructions Per Second (MIPS). Throughput is calculated based on working load size and response time. To obtain a statistically representative calculation, results are based on the 50 repeated experiments, average readings are determined based on the output metrics of response time, throughput, and number of PE (Processing Elements, CPU cores) for each stage during simulation runtime. Referring to Figure 6; the red dotted line represents the CloudSim policy-based scaling where it is observed that the response time of higher workload increases. At the same time, the other three color lines depict the workload and system behavior with ReSQoV. The model triggers to allocate required resources to VM and maintains the agreed or expected response time. As shown in Figure 6, ReSQoV waits for 15 s before inserting new PEs usable in scalable processors. The Response Time in Definitely No Violation or Normal decision rule in a particular concurrent user load, no resource allocation was triggered and after Probably Violation (PV) and Definitely Violation (DV) more resources were allocated. Results are similar for all repeated experiments. These results show that policy-based scaling response time increased after a certain load (red dotted lines); on the contrary, after adding resources, the response time decreased in the limits as agreed. Figure 6: QoS satisfied Response Time. \begin{table}
\begin{tabular}{c c c c c} \hline \hline  & **Estimate** & **Std. Error** & **\(t\)-Value** & **Pr (>|t|)** \\ \hline
**Contention \(\sigma\)** & 1 & 0.053249 & 18.78 & \textless{}2\times 10^{-16}\) & *** \\
**Coherence \(\lambda\)** & 0.025887 & 0.001111 & 23.29 & \textless{}2\times 10^{-16}\) & *** \\
**coefficient \(\gamma\)** & 61.159017 & 2.588041 & 23.63 & \textless{}2\times 10^{-16}\) & *** \\ \hline \hline Sig: Significance codes: 0 *** 0.001 *** 0.01 * 0.05 * 0.1 * 0.05 * 0.1 * 1. & & \\ \hline \hline \end{tabular}
\end{table} 
Table 5: USL Coefficients; Contention, Coherence modeled values. Figure 7 presents the QoS agreed throughput using USL based ReSQoV compared to policy-based resource allocation. The red dotted line represents the CloudSim policy-based scaling where after a certain workload, throughput decreases. At the same time, the other three lines depict the workload and system behavior with ReSQoV. That adds the required resources and increases and maintains the throughput in defined and expected limits. As shown in Figure 7, ReSQoV waits 15 s before inserting new PEs usable in scalable processors. The throughput in the Definitely No Violation or Normal decision rule in a particular concurrent user load is similar, and no resource allocation is triggered. However, as the user load increases and for Probably Violation and Definitely Violation, more resources are needed to allocate. Figure 8 shows the behavior of the resource allocation to VM.