# Machine Learning Failure-Aware Scheme for Profit Maximization in the Cloud Market
## 5 Results, Analysis, and Discussion  
In this section, we evaluate our proposed security scheme (FS) against an intolerance scheme (IS) in which a failed task is re-added to the waiting queue. Profit and end-to-end delay are the performance metrics used in the comparison. To gauge our scheme's efficacy, we looked at how well it improves a CP's profits while cutting down on client request waiting times. An adequate number of replicates were performed, and the results were averaged to ensure a 95% level of confidence and relative errors of less than 5%. We looked at how the proposed scheme (FS) performs using a variety of settings for the parameters. We examined the performance under different parameter settings. Table 1 shows the parameters used to evaluate the proposed scheme. Although some CRs may have failed, our scheme will continue to process requests from clients. Customers who are unhappy with their service because of machine failure are more likely to consider switching to a different CP, thereby reducing the profits of the CP. Figure 1 depicts the effect of CR failure on the profit of the CP. The figure displays the results of our method (FS) and the intolerance scheme (IS). In the experiment, we took the profit at various percentage values of failed CRs. Clearly, as the number of failed machines \begin{table}
\begin{tabular}{c c} \hline \hline
**Input**: \(F_{t}\), \(a\), and \(\varepsilon\). \\
**Output**: The optimal number of that dedicated to replace failed CRs. \\
1: _Arbitrarily initialize_ \(H_{t}\) _;_ \\
2: _if CR-Failure()_ \\
3: & \{ \\
4: & _while_ (\(|S(F_{t})-a|>\varepsilon\)) \\
5: & \{ \\
6: & _compute_ (\(S(F_{t})\)); \\
7: & \(F_{t+1}=F_{t}-(F_{t}-F_{t-1})=\frac{S(F_{t})-a}{S(F_{t})-S(F_{t-1})}\) \\
8: & \} \\
9: & _return_ \(F_{t+1}\); \\
10: & \} \\
11: & _End_ \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Simulation parameters. increases in the cloud market, the profit of the CP decreases significantly. Fortunately, our technique keeps serving clients if some of the CRs fail. The FS moves failed requests into some CRs that are part of a pool of CRs ready to replace any failed CR. The IS, on the other hand, re-adds the failed requests to the queue and begins looking for available CRs. Because it serves all requests in-service, our scheme outperforms the IS in terms of profit. Figure 2 shows a comparison between our suggested scheme and the IS for the percentage of completed jobs. As the proportion of failed CRs rises, the percentage of jobs that are successfully completed falls for both schemes. The system's capacity to deal with rising client demand is constrained by failed CRs. Instead of canceling them, jobs that have failed are executed by CRs that are dedicated to replication in our system. If a CR in service fails, the CP can decide which CR should take over the failed task. The CP can increase the number of requests it can fulfill by replacing failed CRs. However, the IS places the failed tasks in a queue, which increases the wait time for clients and decreases the proportion of successfully completed jobs. Figure 1: Profit under different percentage of failed CRs. Figure 2: Percentage of executed jobs under different percentage of failed CRs. Figure 3 depicts the size of the replication pool and the number of CRs set aside to replace failed CRs. It is obvious that as more CRs in the cloud market fail, the pool size grows as well. The CP requires more machines to satisfy client requests and perform replication tasks as there are more and more CRs failing. Figure 4 displays the replication pool size as a function of the penalty for CR failure. It is evident that when the penalty cost rises, the pool size expands to minimize additional losses caused by machine failure. As more CRs fail, the CP requires more machines to serve client requests and complete replication activities. On the other hand, as shown in Figure 5, we compare the delay in our suggested scheme and the IS.